Resources

• I have copied and pasted this opinion fromGrowing 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 addingImpl 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 theImpl 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 onTwitter.