Write Interfaces Before Classes

I tend to write an interface before I write a class.

As I'm writing code in Java, I consider the next test case to get working is always getting the appropriate set of code to compile. Writing an interface allows me to get the code compiling quickly without having to be concerned about implementation details. By deferring the implementation decision, I can let the expected behavior of the interface emerge (I tend to write and rewrite interfaces a lot before I settle on something I'm happy with). Only later, when I'm satisfied with the refactoring, do I go back and create a class to fit the interface. Because YouArentGonnaNeedIt, I oftentimes find that the expected behavior of the interface is sufficiently similar to an existing class that I can write an adapter and allows me to be a LazyProgrammer. - MarkAddleman

Does this mean you end up with InterfaceImplementationPairs? (BuildInterfaceImplementationPairs) for every class, or do you refactor them into one when your done? I like getting the code compiling as soon as possible, so I'll try this idea. -- AndersBengtsson

In the cases where I can't write adapters or I can't use an existing class to implement the interface (I believe this is just a special case of the AdapterPattern), I generally do not refactor the interface and class into one because I'm lazy. I use the naming scheme of preceding interfaces with the letter "I" so I do end up with cases of an interface "ISomething" and a class "Something", but I don't really think this clutters the code and it tends to make testing easier since it provides for MockObjects (particularly when coupled with the FactoryPattern).

I have the same desire to see my initial tests pass (i.e. code compiles), but I've found it's just as easy to create a concrete class with dummy method implementations (in fact VAJ and Eclipse do it automatically). Then I'll refactor an interface (or interfaces) out of the concrete class if/when I need it. I generally consider OneToOneAndOnto? interface/class relationships to be misleading. I use an interface to indicate the presence of an abstract type with multiple implementations. - GeoffSobering

Upon reflection I realized that I do often create interfaces when there is only one production implementation class. For exactly the same reason mentioned above: testing often (sometimes?) requires the ability to create stand-in implementations (I prefer PseudoClasses to mocks, but that's just me...). With that admission out of the way, I do tend to postpone the extraction of the interface until it is clear that the test will require the injection of a stand-in. Sometimes that is almost immediate, but sometimes it is never... - GeoffSobering

Hmm. At the risk of sounding like Yet Another Tape Loop let me point out that the interfaces should have come directly out of the design. If you had a clean design to start with then you'd know what the class interactions would be, the services offered by each class, and thus the interfaces required to get data in to and out of each class. If you don't have a good design then you'll be forever fudging this stuff, trying to figure out where the division of labor is and what data is handled by what unit of computation. Not a good situation in which to be. Eh? -- MartySchrader

Actually, as an IncrementalDesign? aficionado, it is exactly the situation I like to be in (but that's a topic well hashed-out in the BigDesignUpFront vs. alternatives discussions). It seems this topic is more about the tactical decision between always creating an interface vs. creating interfaces as necessary. - GeoffSobering

AhHa. This is the primary difference in your approach to mine. You are treating design and component interfaces as tactical, whereas I see this stuff as strategic in its nature. If a proper design is done off of a known-good architecture then the design -- and the interfaces which represent it -- won't be changing willy-nilly. On the other hand, if you have "postponed" design decisions to the point of coding then you might be massaging these things for quite some time. I really, really prefer to have design decisions out of the way when it comes time to put the code together. -- MartySchrader

See: MaxThreeLayersOfInheritance

CategoryInterface