0

I'm working on a set of automated tests that we use internally at work. Lately, we've been designing classes that implement interfaces in addition to inheritance.

As I understand it, interfaces in Java are used to fulfill a contract. A class that implements an interface must include implementations of any members of that interface. This works really well for building libraries or objects that are meant to be used by outside teams or individuals since it guarantees certain methods will be present.

What about code that's entirely kept within a single team in a single location? (Assume this code will stay internal, or else this question changes entirely.) If I can simply go to my VCS history or ask a team-member about changes to code, do I really need to enforce these changes using interfaces? Even if a team is large, you could still develop conventions or tests to verify things. I feel like we're just making more work for ourselves by using interfaces, but maybe there are additional arguments.

NOTE: This project is a Java project and will stay that way. Interfaces here are instances of interface with all the syntax and rules that apply.

Benjamin Pollack
  • 1,183
  • 9
  • 15
joshin4colours
  • 3,678
  • 1
  • 24
  • 37
  • 3
    Interfaces don't enforce contracts, they specify them. Slapping an interface on a class doesn't guarantee people will implement it correctly. You use an interface if you need to be able to switch implementations of some abstraction. – Doval May 15 '14 at 16:50
  • I actually just don't think I'm being quite clear enough. Or it's not a great question :) – joshin4colours May 15 '14 at 19:07

2 Answers2

2

Let's clarify a few things.

First, the primary purpose of an interface is to allow multiple implementations. If there's only one implementation, you don't need an interface; the class already defines its own public API. Some unit testing scenarios require interfaces, because a mock is an alternate implementation.

While an interface specifies an API, it doesn't necessarily specify a contract, per se. Contracts have additional things in them like restrictions on parameter values, which interfaces lack. An implementing class merely fulfills the interface's API.

While it's true that you are required to implement all of the members of an interface, that implementation could merely throw an UnsupportedOperationException.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • Great description of interfaces, but this doesn't quite answer my question. – joshin4colours May 15 '14 at 17:05
  • 1
    Hopefully, it tells you what the appropriate uses for interfaces are (addressing the specific points you made in your question), so that you can make up your own mind, based on your own specific software requirements. – Robert Harvey May 15 '14 at 17:06
0

The main point of an interface is not to hide things so that evil contract programmers cannot exploit things they haven't paid for. It's to simplify the conceptual task of dealing with a module.

Knowing only the minimum about a class that is necessary for using its services is good. If the class exposed more detail than is necessary, the user will inevitably add this to their mental model of the class, and since memory, attention etc. are finite, this is wasted effort that might be lacking in other, more important places.

All this applies to other programmers just as much as to your own team or even to yourself. Using a class you yourself have written without knowing details of its implementation is very good sign. It shows that you have successfully solved a task once and once only, and moved on to other, higher-level tasks. Interfaces are a valuable tool for achieving this (among other things, such as e.g. multiple implementations), therefore the reasons for using them have nothing to do with how many developers or what kind of team interact with a class.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310