2008/11/26 Greg A. Woods; Planix, Inc. woods@planix.ca:
On 25-Nov-2008, at 7:57 PM, Igor Stasenko wrote:
I like the idea of hiding the state/storage specific details from eyes of subclasses. It makes irrelevant, in what format or where particular object holds its state. As long as you providing messages to access it, it could be anything.
So why not just get rid of instance variables completely? :-)
I think Ramon Leon hit the nail on the head. You're not supposed to try to protect anything in a class definition from any of its subclasses. Inheritance is a mechanism to _expand_ upon the definition of a class, not restrict it.
An instance of an object contains all of the components (instance variables, methods, etc.) of the class it belongs to as well as, by definition, all of the components from any (and all) class(es) it inherits from. That's the whole idea, as I understand it, underlying the concept of inheritance.
An object shouldn't have to use accessor methods to get at its own internal state, no matter where in the class hierarchy its state may be defined. "super" is only needed to get around explicit re-definitions done by the subclass.
My understanding of inheritance is different, in short: A subclass of particular class is a _specialization_ of base class, not _expansion_.
An instance of subclass provides same interface as base class, but with possibly different behavior (because of overrides) or provide additional specialized interface (by introducing new methods).
If you look from a user's point of view (outside a class), you could only send a messages to it. So, for you, as for user its not relevant where an object holds its state - you only interested in its behavior/interface.
As for subclass - a subclass interested in inheriting same interface as base class. Inheriting a state information having a little importance, its just an implementation detail for outside user of class, because anyways he unable to operate with this state directly.
-- Greg A. Woods; Planix, Inc. woods@planix.ca