Welcome to the Treehouse Community

The Treehouse Community is a meeting place for developers, designers, and programmers of all backgrounds and skill levels to get support. Collaborate here on code errors or bugs that you need feedback on, or asking for an extra set of eyes on your latest project. Join thousands of Treehouse students and alumni in the community today. (Note: Only Treehouse students can comment or ask questions, but non-students are welcome to browse our conversations.)

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and a supportive community. Start your free trial today.

Java Spring with Hibernate Data-Driven Application Design Writing Your First DAO

Impl classes are evil?

Since Chris went with the approach of adding the suffix of "Impl" to the class implementing the interface and then placed them in the same package, what are your thoughts on this informative article: https://octoperf.com/blog/2016/10/27/impl-classes-are-evil/

where the author says that

"It’s useless if you tie the contract and the implementation together. The purpose of an implementation is to be replaceable when it comes to dependency injection. By injecting interfaces instead of implementations, you allow the implementation to be replaced by another as the code doesn’t depend on it.

By shipping both the interface and the implementation tied together, you will never be able to replace the implementation with another without editing the code. That’s what most of the developers don’t understand, because they’ve just shipped interfaces with Impl all their life.

Shipping interface and its implementation together is like shipping rims with unreplaceable tires. Who wants this?"

So, my question is, what's the alternative? Should we, for instance, define the implementation class in a different package?

Thanks!

Chris Ramacciotti

Craig Dennis