[Tutor] When to use classes

[Alan Gauld]

On 20/08/17 02:08, Steven D'Aprano wrote:

> Raymond Hettinger has a good video presentation about the use of classes 
> and inheritance for delegating work. (That is not to be confused with 
> delegation as an alternative to inheritance.)

No, but I think it would have been useful if he had made that
distinction explicit. Many people hear delegation and think
one thing, and especially when he also threw in the word
re-use which is often the excuse for misuse of inheritance.

> The Art of Subclassing
> 
> http://www.youtube.com/watch?v=miGolgp9xq8

> Raymond talks about inheritance as expressing a parent-child 
> relationship, where the child can delegate tasks to the parent, but the 
> child doesn't necessarily need to be seen as "a kind of" whatever the 
> parent is.

While I actually agree with much of what Raymond says I think
he fell into the trap that is very common in conference talks
 - an expert talking to other experts missing out some important
assumed knowledge.

In particular he talks about choosing the subclass pattern
that maximises reuse of code. What he did not say, however,
was that you should use inheritance as a means of reusing
code - that's a very different thing and usually has
bad results. But a naive viewer could come away from his
talk with the idea that he was advocating that, and I
don't believe he was. It is true that the amount of
code-reuse is a strong indicator of which way round
a parent-child relationship would go but we shouldn't
inherit a class just to reuse some method within it.

Unfortunately he used the old Circle-Ellipse case (he could
equally have used the square-rectangle conundrum) and
implied that there were two solutions, neither ideal.
What he omitted is the third solution, that most OOP gurus
now recommend, that circles and ellipses are not the
same and should therefore both inherit as peers from
Shape. That implies less code reuse but avoids the
problem of trying to force circles to behave as ellipses
or vice-versa.

He did emphasise the importance of substitution and of
using the LSP (and specifically deviations from it)
as a tool for identifying where the class(and sub-class)
designer has to do extra work to support future sub-classing.

> That's the model used by mixin classes (or traits, a variation on 
> mixins).

That's true, although the big difference is that mixins
are an implementation level of inheritance rather
than conceptual. (ie a class that uses mixins will nearly
always have a "true" kind-of inheritance in its superclasses
too) Also classes intended for use as mixins usually provide
a capability rather than representing a real-world object.
(eg persistence, serializability, logging, security etc)
They are a code reuse mechanism rather than part of the
conceptual framework of the object model. Mixins are a
great way to turn a purely abstract conceptual model into
a concrete implementation fit for the real world without
breaking the integrity of the original concept.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos