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 _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
