Re:Class Hierarchies? Don't Do That
by peterashford on Sunday March 30, 2014 @07:56PM
(#7498548)
Yes! What's wrong in the original article is that the the subclasses have inherited access to all the base classes' internals. There is no reason to allow that at all - the base class should hide it's implementation and allow subclasses to specialise via public methods. One could an interface for this if it was useful - which it would be for a library designer, for example.
Re:Class Hierarchies? Don't Do That
by AnimalMuppet on Monday March 31, 2014 @02:36PM
(#7503276)
Except that you can't do that in JavaScript, which is the language the article is (directly) talking about.
But he takes lessons from a language that has no access control to member variables, and tries to apply them to all OO languages. That's the problem with the article, IMHO.
Re:Class Hierarchies? Don't Do That
by peterashford on Monday March 31, 2014 @04:53PM
(#7504081)
Yeah, I agree. I didn't make that clear and I should have.
Your point about "don't access superclass variables" is also spot-on--I don't see how he misses that "self-enforce not calling other objects' properties" (because the language doesn't do it for you) is really not very different than "self-enforce not calling superclass properties".
Per his article, I agree that fragile base classes are a problem, but not every base class is automatically fragile--you can design an API for subclasses (in Java/C# worlds, by being very explicit/thoughtful about what you make private vs protected), just like you design an API for external callers.