Really See The Objects

Often the Objects in an OO system are abstract concepts, metaphors for the programmer. But sometimes, the Objects directly correspond to something the user also perceives as an object, for instance, in a game, with pieces on a board, or in the interface of a vector-based drawing package.

There is value to this is in teaching or researching OO, because it is easier for a beginner to wrap their head around OO when they can ReallySeeTheObjects.

Someone else care to add comments? I don't want to drone on about video games, even if they are a classic example of OOP :} But I would recommend OO tutors checking out systems like LPC or MOO as providing an explorative environment for OO -- CanisLupus

Or maybe SelfLanguage (or SmallTalk!). There's a subtle danger here: my introduction to Self was through a BCS OOPS meeting where a chap who was using Self as a teaching tool came along and did a presentation. He conceded that in fact this might not be doing the students too many favours, since they would most likely graduate from this happy world of direct manipulation and end up in industry writing C++ header files (this was a few years ago).

OO education is a tricky area. Many examples from OO simply do not work when translated into practical OO languages. For instance, the classic class hierarchy:

 Polygon -> Rectangle -> Square

This is found in many beginning OO texts. When the poor beginner tries to implement this class hierarchy in C++ he becomes hopelessly lost. It is not until you begin to study DesignPatterns that possible solutions become apparent - and they are not simple!

Also, this idea seems (to me) to be against ExtremeProgramming. The code tells you what objects you need. If you naively try to map physical things onto objects you often discover that the physical thing is really an compound object or at least multiply-inherits.

On the other hand, it is certainly valuable to come up with good mappings from the physical domain to the computing domain ... it just annoys me that the classic examples, such as that above, collapse under close scrutiny. -- EddieEdwards

Which is why I recommend, rather than giving what looks like a practical example (but isn't) in theoretical language and having the student's brain implode when they try and shift it to reality, they could, perhaps, start with a real, practical, if slightly "toy" OO language/environment such as MOOs and LPCs. You have multiple users, who can communicate and assist each other. You have a shared virtual space. And everything in that space, including the users, is modeled by one or more classes.

The idea is that:

It's an already-written, real, functional system which they can then extend using OO techniques, in the process, enriching the teaching environment itself
Unlike the dodgy examples given in some books, it doesn't "collapse under close scrutiny", because it is a working system in practical use
Some people just get their "aha! moment" (ie grok OOP) quicker when they can see the objects and relationships in front of them as "real-world" objects that they can manipulate in a natural way first.

(Well, sort-of. "take apple". "put apple in backpack"...)

Anyway, it's just a cute theory. :}

-- CanisLupus

Reminds me of an example that BertrandMeyer pointed out from a textbook, where CarOwner? extends Person and Car.

After a bad accident, no doubt.

If Poly>Rect>Square is taught in any text, the text is wrong and the author needs to go back to OO school. The isA and isaKinda relations are a diversion, misleading and often wrong, as in the geometry case.

The fundamental relation is "inheritsFrom". The child inherits all of the parent's attributes and behaviours, so the child can always be used when the parent is called for. The child exists because there was a reason to do something not in the parent, so the parent can not be used in place of the child. Simple and easy to apply.

That is universal. Sometimes it maps to an isA, but not always; it's irrelevant and to avoid confusion should never be mentioned. The proper class hierarchy for the geometry places the square at the top. You can always use a polygon to make any square but not vice-versa. If you put the polygon at the top, the rectangle and square inherit all its features and add no new ones, so the hierarchy is a nullity.

This is also the more desirable from an efficiency point of view, since it saves us carrying all of the polygon's attributes with every square object. In the real world this is all moot, since we generalize to a "shape" with lists of features.

The fact that isA sometimes works is not an excuse for muddying the waters with it.

--MarcThibault 2010-09-20