» Killing Speculative Generality Code Smell » Managed Chaos by Naresh Jain

Killing Speculative Generality Code Smell

I’m just reviewing a project’s code. I found a common pattern used in their code base. Every class implements an Interface. Each interface is only implemented by one class. Even more interesting, this interface is not exposed outside. In other words, its not exposed as part of the API.

Then my question is

Why do we need the interface? Why can’t we just use the class directly?

Apparently there is no valid answer. Some told me,

Spring forces you to have interfaces.
- That’s not true.
Some told me their mocking framework does not support mocking a class.
- This is also not true. Most mocking frameworks come with a class extension. Some new frameworks, don’t even distinguish between an interface and a class.

Anyway, we don’t need one stupid interface for every class we create. YAGNI. When we need it, we’ll create it. This is one form of speculative generality code smell.

Go ahead, kill it!

This entry was posted on Friday, June 26th, 2009 at 7:54 PM and is filed under Agile, Design, Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

http://www.atalasoft.com/cs/blogs/rickm/ Rick Minerich

While creating an interface for EVERY class is overkill, I sometimes do like to use internal interfaces. It’s a very effective way to decouple classes or invert the reference hierarchy of friend assemblies.

As an example, I sometimes use interfaces as an alternative to mock frameworks for testing.
http://www.atalasoft.com/cs/blogs/rickm/ Rick Minerich

While creating an interface for EVERY class is overkill, I sometimes do like to use internal interfaces. It’s a very effective way to decouple classes or invert the reference hierarchy of friend assemblies.

As an example, I sometimes use interfaces as an alternative to mock frameworks for testing.
http://binkley.blogspot.com/ B. K. Oxley (binkley)

Amen, brother.

I run into this ant-pattern at work most often with intermediate developers. The journeymen developers don’t think to make the interfaces, and the master developers have reached your conclusion.
http://binkley.blogspot.com B. K. Oxley (binkley)

Amen, brother.

I run into this ant-pattern at work most often with intermediate developers. The journeymen developers don’t think to make the interfaces, and the master developers have reached your conclusion.
http://www.magicindian.com/ Ravi Mohan

I think it is a bad idea to have every class extend an interface, but perhaps the developers are being *very* clever by distinguishing types (in the type theory sense) from classes.

Well, no I don’t think that is what’s really happening, and it is certainly not an appropriate use of java.
http://www.magicindian.com Ravi Mohan

I think it is a bad idea to have every class extend an interface, but perhaps the developers are being *very* clever by distinguishing types (in the type theory sense) from classes.

Well, no I don’t think that is what’s really happening, and it is certainly not an appropriate use of java.
http://agilefaqs.com/nareshjain.html Naresh Jain

Good point Rick. Certainly I’m not suggesting, not to use interfaces. They can be very powerful tools for abstraction and decoupling.

Either extremes is bad. No interface or every class inheriting from an interface.
http://agilefaqs.com/nareshjain.html Naresh Jain

Good point Rick. Certainly I’m not suggesting, not to use interfaces. They can be very powerful tools for abstraction and decoupling.

Either extremes is bad. No interface or every class inheriting from an interface.