Not to derail too much, but.<p>I had a textbook that started to explain OOP by basically saying &quot;A dog is a class. A dog has a tail that can be in a wagging state or not. A dog has a name...&quot;<p>And I&#x27;m sitting there thinking &quot;No, dog&#x27;s don&#x27;t &#x27;have&#x27; names. We call them names and they respond to names. They sometimes know their name. It&#x27;s a different kind of &#x27;have&#x27; than having a tail. I have a name for my dog. Should the person class have a dogs_name member variable now?&quot; A tail is a subset of a dog. A name is a property of the abstract system in which the dog resides.<p>A class is a model of something else. You can model a dog with an object, but you can&#x27;t know how good of a model it is unless you dig down into it and see where it breaks down. It <i>will</i> break down, because software is an abstraction, and abstractions, being abstract, are <i>not</i> the things they are abstractions of. And there are not many things that behave like OO objects because they are far too simple to represent reality in any high-fidelity sense. And it&#x27;s dishonest to pretend they do.<p>Not to say there isn&#x27;t some pedagogical advantage to using the analogy, I just think a better one could be used. Like talking about messages or something.