In The Age Of DRYness - Do We Really Need Naming Conventions For Interfaces?

Hi Adam,

Another usual pattern is also:

Service service = new DefaultService();

There are also four good reasons for never exposing the implementation class:

1. The good old Design Patterns advice: "program to the interface not to the implementation"; this will let you change the current implementation with another one should the need arise over time;
2. In a software engineering world where automated testing, dependency injection and mocking are becoming increasingly popular techniques, interfaces let you mock the implementations without recurring to (what I define) tricks like using ASM or CGLIB. You can simply mock an interface by creating a new concrete one which contains the behaviour needed for testing, without recurring to frameworks.
3. It's perhaps a rephrasing of point 1., but you may want to use an interface simply because that  class represents an "extension point" and, although you still do not have multiple implementations, you may want your architecture to cater for it.
4. Because refactoring and extracting an interface out of a class later in the development cycle can be cumbersome - developers using methods that should not belong to the interface, etc. We have all seen that.

Ciao,

Alessandro

Hi Adam,

In my opinion the interface is matter for the maintenance and the evolution of the software: it's an indication, a landmark about the interanl stucture of the program (the concept of program to the interface not to the implementation quoted by Santini).

 For example you have the code

ServiceIF service = new Service();

 and you prefer to re-write as 

 Service service = new Service(); 

( Service is a concrete class and ServiceIF is an interface)

Later, the customer ask you to extend the function of a software component.

The solution iscreate a new class NewService (horrible name but it's an example :)) sharing the public behaviour of Service.

With the first solution, you can write

 public class NewService implements ServiceIF//bla bla

  with the other solution

 public class NewService

and you must be more careful for the regression test.

 At the least, I think the the interface implemented by one class is an assurance for the future ;)

The bad practise, IMOH, is to use name as

ServiceIf, IService, ServiceInterface

  instead a name closer to functional world.

Bye

Alessandro

1. The advice from the Design Patterns book wasn't meant to be read as "create separate interfaces for everything", but as "if you have a separate interface already, then use it to declare your variables, fields, parameters and return types, instead of using the implementation type".
2. java.lang.reflect.Proxy is as much a "trick" as ASM or CGLIB. In reality, these are simply implementations mechanisms used internally by mocking tools, which users don't really have to know about. In the end, it's the code you write in your unit tests that matter, not the code that the tool providers need to write. And writing mocks by hand is far from effective or productive, if you consider how easy it can be to use a good mocking tool.
3. Creating a separate interface without a real need is pure over-engineering, which adds certain cost in exchange for a dubious eventual benefit. Besides, modern Java IDEs make it easy to introduce them later, should the need arise.
4. It can be cumbersome, but it can also be quick and easy. If you do create the interface up-front, then you and everyone else will inevitably pay the price for the extra complexity, for the whole life of the project.

I certainly agree that misuse of what I am saying can lead to overengineering; on the other hand, misuse of the technique described in this post (and you) can lead to poorly maintainable designs.

I also agree that developers should be unaware of CGLIB and ASM; on the other hand, I have seen too many times people writing a final class and then trying to create a mock for it.

I have also seen too many developers adding methods to classes just because they "needed it". Architecture is much safer from being tampered with improper coding.

Last but not least,  have seen way more situations in which people wished they had written an interfaces upfront than the other way around.

The bottom line: everything should be done cum grano salis, and this is no exception. However, I still prefer to have one interface more than one less. After all, a Push Down refactoring is not that complicated and can be done after I am absolutely sure there is no need for such an interface.

Ciao,

Alessandro