5 ms·
It's a strawman because his argument is "avoid class hierarchies" but it is not "class hierarchies" that gives rise to this problem it's accessing the private s
by timv 13y ago
It's a strawman because his argument is "avoid class hierarchies" but it is not "class hierarchies" that gives rise to this problem it's accessing the private state of another class.
His concluding remarks about class hierarchies are: "Class hierarchies create brittle programs that are difficult to modify.", but he hasn't established that - he's only shown that ignoring encapsulation within a class hierarchy creates brittle programs.
If he wants to argue that class hierarchies encourage that sort of behaviour, and should therefore be avoided, then he is welcome to, but he didn't make that argument.
His evidence only shows that breaking encapsulation is bad, even if it is contained inside a class hierarchy. That make it a strawman because the thing he has torn down is not the thing he is arguing against.
- jonahx 13y agoHe's established both things. First, that class hierarchies are bad when they break encapsulation (he calls this the engineering problem with them). But he also argues that they don't accommodate change well by their nature (he refers to this as the semantic problem): >> Furthermore, the idea of building software on top of a tree-shaped ontology would be broken even if our knowledge fit neatly into a tree. Ontologies are not used to build the real world, they are used to describe it from observation. As we learn more, we are constantly updating our ontology, sometimes moving everything around. >> In software, this is incredibly destructive: Moving everything around breaks everything. In the real world, the humble Platypus does not care if we rearrange the ontology, because we didn’t use the ontology to build Australia, just to describe what we found there.
- 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).