The new developer is not familiar with the system and changes getTotalHours so that it returns the value times -1. generateHoursReport now works as expected, but pay is now very broken. The change requested in one method affected the other.
Not any one pattern is good for everything, but in the case of inheritance, that particular example describes an incompetent developer rather than a negative point against inheritance: a developer should fully understand the code they are working in.
As an example, I could say that functional programming (without classes) is flawed, and I could change one word in that example, but it won't do justice to the topic of describing actual flaws:
The change requested in one function affected the other.
Maybe the article can describe why exactly the developer felt inclined to modify a function/method without checking how it propagates into the rest of the program. Was there actually a reason inheritance made it more likely for the developer to make that mistake in that example?
For the past 10 years, I had the opportunity to work in various types of projects, in a number of industries. In that time I have developed some thoughts about software and the process of creating it.
I've had the misfortune of working on systems that had a giant inheritance tree, and it can get extremely difficult to understand completely all possible connections.
I agree that the example is "too simple" and has the blame on the developer, not the design. You could also claim that a good suite of unit tests would detect this breaking change.
But, with inheritance you could get into a situation where the two functionalities can share the same code, exposing the system to this type of breaking change. Something that is much less likely to happen with a less coupled approach of composition and delegation.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Not any one pattern is good for everything, but in the case of inheritance, that particular example describes an incompetent developer rather than a negative point against inheritance: a developer should fully understand the code they are working in.
As an example, I could say that functional programming (without classes) is flawed, and I could change one word in that example, but it won't do justice to the topic of describing actual flaws:
Maybe the article can describe why exactly the developer felt inclined to modify a function/method without checking how it propagates into the rest of the program. Was there actually a reason inheritance made it more likely for the developer to make that mistake in that example?
A bad developer can break any system...
I've had the misfortune of working on systems that had a giant inheritance tree, and it can get extremely difficult to understand completely all possible connections.
I agree that the example is "too simple" and has the blame on the developer, not the design. You could also claim that a good suite of unit tests would detect this breaking change.
But, with inheritance you could get into a situation where the two functionalities can share the same code, exposing the system to this type of breaking change. Something that is much less likely to happen with a less coupled approach of composition and delegation.