How do objects relate to other concepts in design methods?

Remember entity-relationship models? SSADM, JSD and so on have a notion of entity. These are really objects. All we are doing in object modelling is relabelling entity modelling. However, we put the emphasis on capturing and grouping together both functions and data (operations and attributes in our terminology). That is the elegant simplicity of object modelling. We will look at object models later which look remarkably like entity-relationship models (because they are).

We will now look one powerful way of arranging objects - inheritance hierarchies.

Inheritance

Often we will find that there are objects which have something in common. It is then useful to create an abstract object which groups together the common features, and to use inheritance to define the original objects. For example, consider our two fairy story creatures:

Now we can see that they both have the same operations "arrive" and "meet". We can therefore create an abstract creature:

which has the common operations. We can then draw the original objects grouped under the abstract object as follows

Inheritance means that all the attributes and operations of an abstract object are available in the specialised object below. The triangle in the diagram indicates inheritance. The point of the triangle indicates where operations and attributes are inherited from.

Now we can enter a debate about whether nose, teeth and appetite are characteristics of all creatures or not. It they are, we can revise the diagram above as:

By this device Red Riding Hood has also appetite, nose and teeth as operations. The latter two may be of relevance when she goes to charm the woodcutter, provided they are petite and pearly bright respectively.

Okay, so let's have some more practical examples for those of you who have to do real work. Firstly, the frighteningly dull student-lecturer example. You can do the same with the equally dull employee-customer example.

Or more interesting (only a bit):

Inheritance can pass down an arbitrarily deep hierarchy. A slightly more complicated hierarchy is given below to describe objects which can be juggled.

Now we see that a tennis ball has attributes diameter and weight, and operations catch, pick up, drop,throw and bounce. Objects accumulate all the attributes and operations of the objects above them in an inheritance hierarchy.

The big deal about inheritance

Inheritance is considered good for the software re-use and for clarity of description.

Re-use

When new objects are created which are similar to other objects, they can have many of their attributes and operations ready defined. Let us suppose we now introduce Grandma into our fairy story hierarchy.

Here we get a Grandma who already had an appetite, nose and teeth and who can arrive and meet. Actually these are not in the normal scope of the fairy story, but the principle should be clear.

We might be writing a simple geometry program:

Now to add circles we simply put in another object under 2D shape.

So the circle object need not define the area and position attributes or the get area operation.

It is now possible to buy or obtain ready-built class hierarchies written in object-oriented languages which can be extended in this way to produce a new application.

Designing complex class hierarchies takes time and good design requires experience. But the basic principles outlined above, with some intuitive guidelines, are the basis for the design of good, re-usable designs.

Re-use can be viewed from two directions. Components can be re-used, which is a sort of bottom-up approach to re-use. Or designs can be re-used. Both elements are important in the production of re-usable software.