4 ms·
> He's established both things. First, that class hierarchies are bad when they break encapsulation (he calls this the engineering problem with them). His exac
by timv 13y ago
> He's established both things. First, that class hierarchies are bad when they break encapsulation (he calls this the engineering problem with them).
His exact quote was "Class hierarchies create brittle programs that are difficult to modify."
But he has not demonstrated the first part of that except in one specific case. That case may (?) be common, but it not inherent in the problem - class hierarchies do not require breaking encapsulation.
His conclusion is not supported by his argument because his argument applies only the the strawman he created, and not to the general case to which his conclusion refers.
- AnimalMuppet 13y agoIf I may try to split the difference: His argument applies much more when trying to do OO in JavaScript, because it's much harder to avoid using the parent class's data when you don't have private variables.
- timv 13y agoAbsolutely. But that's a universal issue with JavaScript OO in that it provides no direct language support for encapsulation. Developers have, for the most part, learnt to be disciplined about not accessing "private" fields in JS objects. That they (we) have not learnt to apply that lesson with respect to class hierarchies is evidence for how willingly we throw away good principles when we are working in a "special case". It is also a lesson in why having language features that force developers into good practices is sometimes a net win, even though we might also rally against them (because we dislike their verbosity and/or hand-holding).