Code Smell 135 - Interfaces With just One Realization
Being generic and foreseeing the future is good.
TL;DR: Don't over-generalize
Problems
Speculative Design
Complexity
Over-Engineering
Solutions
- Remove the interface until you get more examples
Context
In the past, programmers told us to design for change.
Nowadays, We follow the scientific method.
Whenever we find a duplication we remove it.
Not before.
Sample Code
Wrong
public interface Vehicle {
public void start();
public void stop();
}
public class Car implements Vehicle {
public void start() {
System.out.println("Running...");
}
public void stop() {
System.out.println("Stopping...");
}
}
// No more vehicles??
Right
public class Car {
public void start() {
System.out.println("Running...");
}
public void stop() {
System.out.println("Stopping...");
}
}
// Wait until more vehicles are discovered
Detection
[X] Automatic
This is very easy for our linters since they can trace this error at compile time.
Exceptions
This rule applies to inter system definition and business logic.
Some frameworks define an Interface as protocol to be fulfilled.
On our bijections we need to model existing real world protocols.
Interfaces are the MAPPER correspondence to protocol.
Dependency injection protocols declare interfaces that are fulfilled with their realizations. Until then, they can be empty.
Tags
- Over Design
Relations
Conclusion
We need to wait for abstractions and not be creative and speculative
Credits
Photo by Brian Kostiuk on Unsplash
I love software, because if you can imagine something, you can build it.
Ray Ozzie
This article is part of the CodeSmell Series.
About the author
I鈥檓 a senior software engineer loving clean code, and declarative designs. S.O.L.I.D. and agile methodologies fan.
Comments
Join the discussionAgreed!
Great article.
Maxi, let it go to 1K(articles from this series)
Let's stress test Hashnode platform :)
What do you think of interfaces implemented by only one class, when that class represents a Service and not a DTO?
Something like
public interface IDoSomething{
void Do();
}
public class DoSomething : IDoSomething{
void Do();
}
IDoSomething is a name problem. I've never seen an IDoSomething in real world. I assume it is a bad convention.
If this a service provided as an API interface for other systems it might suit the Exceptions scenario.
If it is for internal use is a code smell on premature generalization
Great article again, Maxi. I love your series. 馃槉
Code Smells
In this series, we will see several symptoms and situations that make us doubt the quality of our developments. We will present possible solutions. Most are just clues. They are no hard rules.
