[Pharo-dev] About abuse of inheritance

On 19 July 2013 16:17, Tudor Girba <[hidden email]> wrote:
> Hi Igor,
>
> I love these discussions. I agree that abusing inheritance is
> counter-productive. Definitely, "Shampoo subclass: #Shower" does not match
> any mental model I can think of. But, I am not seeing "Announcer subclass:
> #MyDomainConcept" equally as an abuse.
>
> Here is why.
>
> When I say "Object subclass: #MyDomainConcept", my actual intention is not
> to reuse types necessarily, but rather the infrastructure needed for the
> Smalltalk runtime. From this point of view, it is an implementation
> inheritance. I could as well, inherit from ProtoObject, but I do not do it
> because Object gives me a bit more technical infrastructure.
>
> For me, Announcer is nothing but an Object that has an extra technical
> capability. Inheriting from Announcer rather than Object seems the same as
> inheriting from Object rather than ProtoObject.
>
> Now, you can shoot.
>

As i understood, you see nothing wrong in using inheritance as reuse,
while i do.

The argument with Object does not stands, to my thinking, because
it is most generic class, and protocols it implements used by various
parts of a system,
including reflection etc,
and those parts actually expecting that all objects they dealing with
is at least implementing Object protocol(s).
So, strictly speaking by inheriting from Object you may call it reuse,
but to my thinking it is more
about having a guarantee that your class will play well with the rest
of smalltalk ecosystem (even if it's not your direct concern).

While in case of inheriting from Announcer it is something different:
you already have specific behavior
which is non-universal for all objects in system (otherwise why not
implementing Announcer protocol in Object?).

Also, i am sure you aware, that by doing this, you introducing a
certain degree of rigidness in your model (every time you refer
directly to names instead of protocols, little kittie dies ;)

because if today, Announcer serves well for your needs, and all is happy..
but maybe tomorrow, one guy will make a better one AnnouncerOnSteroids..
and to reuse it , you will need to change the parent in all numerous
classes where you used Announcer
originally.
And to make it absolutely ridiculous, imagine how you will give user a
choice whether use one Announcer or AnnouncerOnSteroids? You will
recompile your classes each time? And what if parts of your model
insist on using just Announcer while others having no problem with
trying to play with AnnouncerOnSteroids?

Another aspect of such abuse is when you inherit, you are tempted to
use direct access to internal state and private methods, and that
leads to really strange and complex problems later..

Just giving you an example:

Suppose we have a class Butter, which implements #numberOfCalories and
#fatPercentage protocols..

Now we do it like that:

Butter subclass: #Fridge

and then, of course

fridge := Fridge new.

fridge fatPercentage

or:

fridge fatPercentage: 10.

^^^ just look at the above line, how much sense you think this piece
of code makes
for reader, who will try to reason what is happens in your code?

And why you think it is not the same story with Announcer?

Because by subclassing from it, you expose its protocol(s) in places
where it is not needed and
will cause problems and confusion.
Because when you inherit to reuse, not to specialize, then users of
such class in most cases won't use
full protocol of the superclass, nor require it.. and therefore by
providing more than necessary,
you are basically violating the principle of least authority.
To fix that, you will need to override certain methods in your
subclass to prevent exposing unwanted/low-level behavior to users. But
that's again wrong, because then your model now starting to know too
much about Announcer's internals, which should be an implementation
detail, and adds even more rigidness to your design.

--
Best regards,
Igor Stasenko.

On 7/19/13, Igor Stasenko <[hidden email]> wrote:
> On 19 July 2013 16:17, Tudor Girba <[hidden email]> wrote:
>> Hi Igor,
>>
>> I love these discussions. I agree that abusing inheritance is
>> counter-productive. Definitely, "Shampoo subclass: #Shower" does not
>> match
>> any mental model I can think of. But, I am not seeing "Announcer
>> subclass:
>> #MyDomainConcept" equally as an abuse.
>>
>> Here is why.
>>
>> When I say "Object subclass: #MyDomainConcept", my actual intention is
>> not
>> to reuse types necessarily, but rather the infrastructure needed for the
>> Smalltalk runtime. From this point of view, it is an implementation
>> inheritance. I could as well, inherit from ProtoObject, but I do not do
>> it
>> because Object gives me a bit more technical infrastructure.
>>
>> For me, Announcer is nothing but an Object that has an extra technical
>> capability. Inheriting from Announcer rather than Object seems the same
>> as
>> inheriting from Object rather than ProtoObject.
>>
>> Now, you can shoot.
>>
>
> As i understood, you see nothing wrong in using inheritance as reuse,
> while i do.

not generally I assume Tudor thinks, only for this particular case of
sub classing Announcer.
Announcing behaviour may be considered part of a package objects
should have and this has  been the case in Smalltalk since the
beginning, though implemented with the symbol based changed/update
mechanism.

To restate
Yes, I agree that subclasses should specialize the behaviour of the
superclass. But there need to be classes first you may subclass to
specialize and these inherit general properties of object behaviour.

--Hannes

> The argument with Object does not stands, to my thinking, because
> it is most generic class, and protocols it implements used by various
> parts of a system,
> including reflection etc,
> and those parts actually expecting that all objects they dealing with
> is at least implementing Object protocol(s).
> So, strictly speaking by inheriting from Object you may call it reuse,
> but to my thinking it is more
> about having a guarantee that your class will play well with the rest
> of smalltalk ecosystem (even if it's not your direct concern).
>
> While in case of inheriting from Announcer it is something different:
> you already have specific behavior
> which is non-universal for all objects in system (otherwise why not
> implementing Announcer protocol in Object?).
>
> Also, i am sure you aware, that by doing this, you introducing a
> certain degree of rigidness in your model (every time you refer
> directly to names instead of protocols, little kittie dies ;)
>
> because if today, Announcer serves well for your needs, and all is happy..
> but maybe tomorrow, one guy will make a better one AnnouncerOnSteroids..
> and to reuse it , you will need to change the parent in all numerous
> classes where you used Announcer
> originally.
> And to make it absolutely ridiculous, imagine how you will give user a
> choice whether use one Announcer or AnnouncerOnSteroids? You will
> recompile your classes each time? And what if parts of your model
> insist on using just Announcer while others having no problem with
> trying to play with AnnouncerOnSteroids?
>
> Another aspect of such abuse is when you inherit, you are tempted to
> use direct access to internal state and private methods, and that
> leads to really strange and complex problems later..
>
> Just giving you an example:
>
> Suppose we have a class Butter, which implements #numberOfCalories and
> #fatPercentage protocols..
>
> Now we do it like that:
>
> Butter subclass: #Fridge
>
> and then, of course
>
> fridge := Fridge new.
>
> fridge fatPercentage
>
> or:
>
> fridge fatPercentage: 10.
>
> ^^^ just look at the above line, how much sense you think this piece
> of code makes
> for reader, who will try to reason what is happens in your code?
>
> And why you think it is not the same story with Announcer?
>
> Because by subclassing from it, you expose its protocol(s) in places
> where it is not needed and
> will cause problems and confusion.
> Because when you inherit to reuse, not to specialize, then users of
> such class in most cases won't use
> full protocol of the superclass, nor require it.. and therefore by
> providing more than necessary,
> you are basically violating the principle of least authority.
> To fix that, you will need to override certain methods in your
> subclass to prevent exposing unwanted/low-level behavior to users. But
> that's again wrong, because then your model now starting to know too
> much about Announcer's internals, which should be an implementation
> detail, and adds even more rigidness to your design.
>
>
> --
> Best regards,
> Igor Stasenko.
>
>