Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trial
sh10
6,225 PointsImpl 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!