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