Impl Classes Are Meaningless

Resources

• I have copied and pasted this opinion from Growing object oriented software guided by tests by Steve 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 an I to the interface, but not by much. A name like BookingImpl is duplication; it says exactly the same as implements Booking, which is a code 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 them

• Thank 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.