In The Age Of DRYness - Do We Really Need Naming Conventions For Interfaces?
During past projects / reviews I found the following naming conventions for interfaces and their realizations:
- IService service = new Service();
- Service service = new ServiceImpl();
- ServiceIF service = new Service();
Each one contains redundant information. Either your are emphasizing the interface, or its implementation. The information is already contained in the source code, so both is redundant.
Such naming conventions are only necessary if you have really no idea how to name the implementation, so instead of thinking about a sound name, its easier to rely on existing template.
The lack of name for the implementation is probably also an indicator for it's unsufficient responsibilities. So if you can not find a proper name for the implementation, it is a good idea to think about removing the interface and exposing directly the implementation - then without strange conventions. Actually there are no such conventions in the JDK. The interfaces and their implementations are often even called differently:
Runnable r = new Thread();
RootPaneContainer c = new JFrame();
TableModel t = new DefaultTableModel();
Remote remote = new UnicastRemoteObject();
The purpose of an interface is the abstraction or decoupling from several implementations. A single implementation do not needs to decoupled with an interface. There are some exceptions from the rule, like the need to use dynamic proxies etc.
An interface realized by a single implementation with strange naming conventions shouldn't be considered as a general best practice...
RootPainContainer? Nice sense of humor there. ;)
Posted by /me on January 19, 2009 at 12:04 PM CET #
@Me
I changed it back :-).
RootPainContainer would be really a nice name for an interface - without convention,
regards,
adam
Posted by Adam Bien on January 19, 2009 at 12:17 PM CET #
Definitively agree.
In a typically layered application with front end, services, DAOs and domain objects interfaces with only one implementation might be okay for testing or dynamic proxying, e.g. in the service or DAO layer. But introducing them by convention for example for each domain object doesn't make any sense.
Why do so many developers do this? My opinion is, that they misunderstand the principle to code against interfaces.
Thanks for that post, Adam.
Posted by Nick on January 19, 2009 at 02:38 PM CET #
Nick,
I have no idea, why interfaces are so overused. Probably because an application with lot of interfaces looks more mature and sophisticated. But you get the duplication of code as well with this approach. ...and at the end the maintainability will suffer.
thanks for the comment!,
adam
Posted by Adam Bien on January 19, 2009 at 03:11 PM CET #
its called "coding to interface". Yes, most of the time that interface is useless, but its best practice.
Posted by raveman on January 19, 2009 at 04:13 PM CET #
Raveman,
can something useless be a best practice?,
thanks,
adam
Posted by Adam Bien on January 19, 2009 at 04:25 PM CET #
Hi!
I'm also totally afflicted by this interface madness! It's good to hear that I'm not the only one.
As far as I can tell, the overuse of interfaces is partially taugth in Universities, often with the argument of making an application more maintainable.
> I have no idea, why interfaces are so overused. Probably because an application with lot of interfaces looks more mature and sophisticated.
I've just seen a student project where interfaces are implemented but not even used anywhere, how grotesque!
With modern IDEs' refactoring support it is one of the easiest things to introduce interfaces and to encapsulate things in an existing project. So if you have no _good_ reasons to do it the other way, the approach without interface and less code should be preferred.
Also many thanks for the post!
Klaus
Posted by Klaus Trainer on January 19, 2009 at 04:41 PM CET #
> its called "coding to interface". Yes, most of the time that interface is useless, but its best practice.
A class has an implicit interface formed from it's public methods. This is the interface that should be coded to (i.e. designed with care); it doesn't matter whether this public interface starts life as an implicit interface in a class, or as a seperate Interface. It can always be extracted from the class later if necessary.
Posted by Joe on January 19, 2009 at 08:05 PM CET #
Don't talk that bad about interfaces. Think about that no GoF Design Pattern would exist if there were no interfaces..and don't tell me you don't like design patterns either... :)
Posted by daniel on January 20, 2009 at 12:44 AM CET #
Daniel,
Interfaces are perfect, but they should be always used with clear defined intention. Just using them as a default approach is not a very good strategy.
Actually most of the GoF patterns are not interface based. The book was written with C++ and Smalltalk examples :-). The classic one, strategy pattern, is interface based. But especially here you would have really good names for the interfaces and their realizations. A Strategy with a single implementation is a strange one...
regards,
adam
Posted by Adam Bien on January 20, 2009 at 09:29 AM CET #
Hi Adam,
generally I agree – only introduce interfaces, if necessary. But I think, sometimes interfaces can be useful, even if only one implementation is intended:
* In a multi-component project, a development team may pass a JAR containing only the public interfaces of their component's services to other teams, who can program against those interfaces. They don't have to cope with the internals of the first team's component and aren't tempted to use its internal classes, as they don't have access to them.
* Using interfaces, one can provide multiple versions of a service (if that's a requirement, e.g. for compatibility reasons), realized by the same class.
* Mostly it's easier to mock interfaces than classes, either with simple ad-hoc implementations or by using tools such as EasyMock (even with EasyMock's class extensions one can't mock final methods etc.).
But as you wrote – whether to introduce interfaces or not should always be contemplated thoroughly.
Gunnar
Posted by Gunnar on January 20, 2009 at 08:09 PM CET #
1. Interfaces are great for unit-testing and multiple implementations. You can create mock implementations from the Interface to act as dependencies while unit-testing.
2. You can also have decorated implementations if you are stick to interfaces (open for extension, closed for modification - OpenClose principle).
IMessageSubmitter (interface)
VanillaMessageSubmitterImpl
ThreadedMessageSubmitterImpl
ThrottlingMessageSubmitterImpl (decorator impl)
See the benefit now? :-)
Posted by Shantanu Kumar on January 21, 2009 at 10:47 AM CET #
I don't understand the core 'complaint' of this post. I think it's pretty clear that you won't build Interfaces e.g. for every single domain object (since they represent business facts you'll directly rely on) but instead for your 'infrastructure' or 'service components' who's implementation might change or you want to provide some kind of decoupling.
Considering Naming conventions of Interfaces and Implementation, the discussion points into the wrong direction: i think Kevlin Henney worked it out pretty well at JAOO 2008 when he spoke about the 'programmers dozen'. In short: worrying about the right names of Interfaces and related Implementation points most of the time to the fact, that the interface is more or less bound to the implementation than to the client (where the Interface belongs to and which is also compliant with the Dependency Inversion Principle!). That said, the name of an interface should focus on the role it will play for the client - so it's saying 'what it is for', not 'what it does' (that's the part of the implementation). Following Henneys advice, you most of time will not come into the mentioned trouble of naming Interfaces and Implementation.
Greetings
Mario
Posted by Mario Gleichmann on January 21, 2009 at 10:50 AM CET #
Interfaces force the programmer to think about promoting internal methods to the public. They don't let the user take any shortcuts that were not intended but possible because some internals slipped through or had to be made protected or public for other reasons (like a used persistence framework).
So programming against interfaces supports best practices and the use of patterns (or at least the thinking thereof). It prevents mistakes.
> Actually there are no such conventions in the JDK.
> The interfaces and their implementations are often even called differently:
> Runnable r = new Thread();
> RootPaneContainer c = new JFrame();
> TableModel t = new DefaultTableModel();
> Remote remote = new UnicastRemoteObject();
> The purpose of an interface is the abstraction or decoupling from several implementations.
> A single implementation do not needs to decoupled with an interface.
I don't get it. In every of this examples there are distinctively different implementations. There is not a crude naming convention like the ones you named at the beginning. So these are examples how it is to be done right?
Posted by Hauke on January 21, 2009 at 11:18 AM CET #
Interfaces force the programmer to think about promoting internal methods to the public. They don't let the user take any shortcuts that were not intended but possible because some internals slipped through or had to be made protected or public for other reasons (like a used persistence framework).
So programming against interfaces supports best practices and the use of patterns (or at least the thinking thereof). It prevents mistakes.
> Actually there are no such conventions in the JDK.
> The interfaces and their implementations are often even called differently:
...
> The purpose of an interface is the abstraction or decoupling from several implementations.
> A single implementation do not needs to decoupled with an interface.
I don't get it. In every of your examples there are distinctively different implementations. There is not a crude naming convention like the ones you named at the beginning. So these are examples how it is to be done right?
Posted by Hauke on January 21, 2009 at 11:19 AM CET #
@Adam
I also often see interfaces for each domain object like value/entity objects. I totally agree that it is an overuse with pure duplication of code. And except for services/DAO, there is in general a single implementation.
A relative majority of people could agree on this: we could establish this overuse of interfaces as a bad practice or perhaps as an anti-pattern.
I think a reason to this overuse is that more and more software providers justify with such poor duplication the use of their own code generator and tools: they create a problem to provide their solution.
Posted by Emeric on January 21, 2009 at 12:22 PM CET #
Hi,
I agree with Gunnar. In an ideal world you would be able to refactor all your code at will to interfaces are required but that assumes you are the controller of the source code. If you are reusing or extending and existing product interfaces are the best way to allow for this.
Just because at the current time and for the current requirements you can't see more than one implementation that is no reason to STOP someone else from creating one in the future.
If you are using IOC it becomes even more relevant as your implementations are not tied to other implementations. As most commenters agree Daos should be interfaces so they can be subsituted for other implementations but this logic proceeds all the way up the tiers and therefore you should not stop this flexibility.
In my opinion interfaces should define the contract for an object if you then choose to create an implementation that implements multiple interfaces you can. E.g. you have two user managers from two different modules in your applications. You an then create on user manager that implements both interfaces keeping your logic together. If the writers of the Modules has NOT created interfaces this would be impossible as you can not multiply inherit classes only interfaces.
Ultimately you can choose to implement you code however you like, if you are writting a component for use by others you should start your implementation by creating interfaces, if you are writting one time use code then you do not need to bother.
Posted by Owen Fellows on January 21, 2009 at 01:14 PM CET #
"1. Interfaces are great for unit-testing and multiple implementations. You can create mock implementations from the Interface to act as dependencies while unit-testing."
I generally agree here, though even with Mock classes you will run into poorly designed interfaces - you really need a couple or real implementations to make sure the interface is flexible enough to allow more then the default implementation.
"2. You can also have decorated implementations if you are stick to interfaces (open for extension, closed for modification - OpenClose principle)."
That, didn't make sense to me.
"IMessageSubmitter (interface)
VanillaMessageSubmitterImpl
ThreadedMessageSubmitterImpl
ThrottlingMessageSubmitterImpl (decorator impl)
See the benefit now? :-)"
Not really,
How about using:
MessageSubmitter (or simply Submitter)
SimpleSubmitter
ParrallelSubmitter
TrottledSubmitter
You don't need 'I' with any decent IDE there shouldn't be need for any descendants of Hungarian-notation or Impl for that matter. - if all else fails just prefix it with default. As soon as there is more then one impl, deprecate the prefixed class, if it doesn't apply any more.
Ether implementations shouldn't be bundled or just make the IDE show the hierarchy of the class
Posted by Michael on January 21, 2009 at 04:01 PM CET #
"1. Interfaces are great for unit-testing and multiple implementations...."
I generally agree here, though even with Mock classes you will run into poorly designed interfaces - you really need a couple or real implementations to make sure the interface is flexible enough to allow more then the default implementation.
"2. You can also have decorated implementations ...."
That, didn't make sense to me.
"IMessageSubmitter (interface)
VanillaMessageSubmitterImpl
ThreadedMessageSubmitterImpl
ThrottlingMessageSubmitterImpl (decorator impl)
See the benefit now? :-)"
Not really,
How about using:
MessageSubmitter (or simply Submitter)
SimpleSubmitter
ParrallelSubmitter
TrottledSubmitter
You don't need 'I' with any decent IDE there shouldn't be need for any descendants of Hungarian-notation or Impl for that matter. - if all else fails just prefix it with default. As soon as there is more then one impl, deprecate the prefixed class, if it doesn't apply any more.
Ether implementations shouldn't be bundled or just make the IDE show the hierarchy of the class
Posted by 62.131.17.150 on January 21, 2009 at 04:02 PM CET #
"1. Interfaces are great for unit-testing and multiple implementations. You can create mock implementations from the Interface to act as dependencies while unit-testing."
I generally agree here, though even with Mock classes you will run into poorly designed interfaces - you really need a couple or real implementations to make sure the interface is flexible enough to allow more then the default implementation.
Posted by michael on January 21, 2009 at 04:03 PM CET #
"2. You can also have decorated implementations...."
That, didn't make sense to me.
"IMessageSubmitter (interface)
VanillaMessageSubmitterImpl
ThreadedMessageSubmitterImpl
ThrottlingMessageSubmitterImpl (decorator impl)
See the benefit now? :-)"
Not really,
How about using:
MessageSubmitter (or simply Submitter)
SimpleSubmitter
ParrallelSubmitter
TrottledSubmitter
You don't need 'I' with any decent IDE there shouldn't be need for any descendants of Hungarian-notation or Impl for that matter. - if all else fails just prefix it with default. As soon as there is more then one impl, deprecate the prefixed class, if it doesn't apply any more.
Posted by michael on January 21, 2009 at 04:06 PM CET #
Amen brother. IInterface and other such practices are one of my pet peeves.
Posted by Rupert Jones on January 22, 2009 at 01:41 AM CET #
Adam,
I agree with you point of view.
I believe that the best practice is to have a clean and meaningfull naming for classes and interfaces.
Meaningfull names doesnt require you to follow the "IInteface" and "implementationClassImpl" conventions.
Posted by Alexandre Verri on January 25, 2009 at 05:00 PM CET #
I think the repetition for having an interface for each domain model object with one implementation is annoying. But the motivation here is not to switch the domain model implementation but the following. If your model gets large you start to split it into severall packages. If you need to access a method in a domain model class in a different package, you have to make this method public. But now the method is also visible to clients of the domain model. In this case there is no way other then to use interfaces, to define the domain model's interface available to clients.
Another matter are services -whatever that is ;-)
Most of the time you have at least a "real" implementation and one for testing purposes. Very often service implementations depend on a special infrastructure and you might want to add different implementations later. At least you want keep the service's clients independant from the infrastructure. So I would conside using interfaces for services a best practices.
Posted by Jan Ortmann on February 13, 2009 at 09:25 AM CET #
Adam Bien... you just know so little....
Posted by Pawel on September 15, 2009 at 05:37 PM CEST #
that funny. today in the morning i read this and thought: right he is. but just a minute ago i just again ran over some idiot who used an abstract class instead of an interface. result i had to instantiate a new class just for the purpose to pass the data over. my class had everything except one thing: java didn't know about it. the result is: redundancy, multiple classes instead of one simple class that allready has everything... for the one sole purpose: make java believe you that this class actually has everything it needs. that also clutters code and makes it errorprone for the created redundancy.
java lacks real (function-)prototypes and multiple inheritance. if you tend to say, thats for the good i'd agree but then use interfaces.
if you aske me:the two most anoying things with java are: use classes instead of interfaces and the keyword "protected". for the latter: it is allways the protected methods you need and hidden by a class inbetween which otherwise had all you need(and you end up reimplementing that class or with loads of deligators ).
i think you know what i mean. ;)
Posted by 88.65.136.0 on March 05, 2010 at 08:49 PM CET #