Why extends is evil

Don't believe everything you read. When you read "xxx is evil" in a programming context, remind yourself that xxx is probably not evil and question everything else in the article. At the very least, a more nuanced understanding of xxx is required. Caleb, I was with you until the end. Now I question everything else you said : — ConditionRacer. Justin You have to draw the line somewhere.

Add a comment. Active Oldest Votes. No, it is not. Since open-closed principle is fine with either, they are not opposed. Reusing base functionality. Specializing behaviour of mostly generic class. Note: evil, adj. Improve this answer. Jan Hudec Jan Hudec Stefan Billiet Stefan Billiet 3, 1 1 gold badge 16 16 silver badges 14 14 bronze badges.

The Post types would all share common behaviour: to display a template that uses the properties associated with the given type of Post. That sounds the same as the shapes example you referenced. Therefore the question about the validity of the pattern, as I had mostly been wary of using Extends due to reading the "Extends is evil" article much before I had learned more about SOLID : — Juha Untinen. Shivan Dragon Shivan Dragon 4, 5 5 gold badges 23 23 silver badges 31 31 bronze badges.

Sign up or log in Sign up using Google. Sign up using Facebook. Sign up using Email and Password. Post as a guest Name. Email Required, but never shown. The Overflow Blog. That being said, the general theme of the article seems to be an emphasis on composition and strategy patterns in situations where you would normally extend.

A problem arises when users of HatchBack start to rely on this one particular base car implementation. But insisting on only composition means manually re-implementing that interface, and not just for the HatchBack, but for every kind of car. Your code example certainly made it clearer how to get around using extends. An even bigger downside is that if your someStandardCarMethod is modified to take a parameter, every single type of car needs to be modified to take that parameter.

Repeated code creates maintainability issues. Extends is probably less evil than repeated code I may try to alter my code base to remove extends, just to see how well it works and how easy it is to remove it. Just as an experiment. A better solution to the base-class issue is encapsulating the data structure instead of using inheritance.

Frameworks an entire class framework that depends on derivation-based customization is brittle in the extreme most of the Agile development methodologies such as Crystal and extreme programming simply won't work unless the code is written in the abstract. If you examine the Gang of Four patterns closely, you'll see that many of them provide ways to eliminate implementation inheritance in favor of interface inheritance, and that's a common characteristic of most patterns.

The significant fact is the one we started with: patterns are discovered, not invented. Patterns emerge when you look at well-written, easily maintainable working code.