> I like to say the class is a "mother ship" and serves as a kind of "home base" or "platform". How about an "amusement park"? ...
I don't think any of that is any better. When explaining OOP, I have two points I try to drive home. 0. you can do anything in any language any way you please. OOP does not give you any new capabilities, it is just a way of keeping your code organized and readable. 1. I describe a parent class and some of the subclasses used in my video processing system parent: find a list of videos to work on, iterate over the list, self.work() on each one. work is defined in the subclasses: subclass 1 - encode subclass 2 - upload subclass 3 - email the URL to the presenter On Wed, Apr 20, 2016 at 3:53 PM, kirby urner <kirby.ur...@gmail.com> wrote: > > I want to suggest that the much-used metaphor (by me included): > > "class is a blueprint, with instances the buildings made from it" > > (houses usually) is a good start, but not nuanced enough to take us all > the way to the end of our story. > > These days I've taken a two pronged approach: yes, OO is meant to model > how we think normally, about things with properties and behaviors. > > "The language gets out of the way and lets you think in terms you're > already familiar with, from work" and such PR, some truth in it... > > ... However (big pause), OO also is it's own knowledge domain with its own > concepts and those are better faced directly and dealt with than dismissed > as mere noise. > > The blueprint metaphor, in being so simple, is maybe too simple, and > therefore dismissive, at least if left in place for too long. > > So yes, OO has its cost, the knowledge domain that is OO with all its > twisted tails of multiple inheritance and the method resolution order. > > But learning that little overhead is more than worth the price of > admission (the PR again). > > The whole idea of inheritance, and of static and class methods, undermines > this simplistic beginning of "blueprint" and so could become corrosive > vectors of entropy (leaking sense), if not contained within more fitting > metaphors. > > I like to say the class is a "mother ship" and serves as a kind of "home > base" or "platform". How about an "amusement park"? > > Each self brings its little __dict__ to the theme park, but all the > "rides" (the "stuff happening") are anchored in the class's __dict__. The > self parameter is like an empty seat in a ride, which the rider's self then > fills. > > This so-called "blueprint" is where the methods are happening, which is so > not what it's like in the case of houses. > > The many instances (the selves) are but little bags of state, little "var > stashes" (uh oh, JavaScript creeping in... :-D). > > Anyway, ya catch my drift, right? > > If we over-stress the blueprint metaphor they'll not be as open minded > about blueprints having their own "batteries included" and doing stuff on > their own, no "selves" need apply in some cases (not all methods need a > self). > > Literal blueprints don't light up and do stuff all on their own like that. > > Our classes often behave a lot more like objects with a life of their own. > > ... and that's true of course as they're each instances of the type > "type", one more example of what that "bag o' tricks" we called 'a class' > might look like. > > Kirby > > > > _______________________________________________ > Edu-sig mailing list > Edu-sig@python.org > https://mail.python.org/mailman/listinfo/edu-sig > >
_______________________________________________ Edu-sig mailing list Edu-sig@python.org https://mail.python.org/mailman/listinfo/edu-sig
