Resources
- I have copied and pasted this opinion from
Growing object oriented software guided by tests
bySteve Freeman, Nat Pryce
- I agree with this opinion but I am curious about what other people think
Impl Classes Are Meaningless
Sometimes we see code with classes named by adding
Impl
to the single interface they implement. This is better than leaving the class name unchanged and prefixing anI
to the interface, but not by much. A name likeBookingImpl
is duplication; it says exactly the same asimplements Booking
, which is acode smell.
We would not be happy with such obvious duplication elsewhere in our code, so we ought to refactor it away.It might just be a naming problem. There’s always something specific about an implementation that can be included in the class name: it might use a bounded collection, communicate over HTTP, use a database for persistence, and so on. A bridging class is even easier to name, since it will belong in one domain but implement interfaces in another.
If there really isn’t a good implementation name, it might mean that the interface is poorly named or designed. Perhaps it’s unfocused because it has too many responsibilities; or it’s named after its implementation rather than its role in the client;
or it’s a value, not an object—this discrepancy sometimes turns up when writing unit tests
Conclusion
Do you agree or disagree with this opinion? All of the classes in my current app follow the
Impl
naming convention. However, after reading this I will be refactoring themThank you for taking the time out of your day to read this blog post of mine. If you have any questions or concerns please comment below or reach out to me on Twitter.
Top comments (0)