Taxonomy and Class Dictionary Graphs

Taxonomy is the science of classication. We discuss class dictionary graph design in the context of two kinds of classications: specialization-centered and parts-centered.

Often a subconcept is simpler than a super concept; for example, a square is simpler than a rectangle. A square is dened by one real number, but a rectangle needs two. So we are tempted to use the following specialization centered class dictionary graph:

158 ^{CHAPTER6. CLASSDICTIONARY GRAPHSANDOBJECTS}

Rectangular : Rectangle | Square *common*

<height> DemNumber

<width> DemNumber.

Rectangle = . Square = .

However, it is better to follow the guideline for

parts-centered

If a subclass needs fewer parts than a superclass, rearrange the parts reecting the dierent needs.

In the context of our example this rule suggests the following class dictionary graph, since a square needs fewer parts than a rectangle.

Rectangular : Rectangle | Square.

Rectangle =

<height> DemNumber

<width> DemNumber.

Square = <length> DemNumber.

This class dictionary graph allows for rectangles that have height = width but are not classied as squares. This is better than in the previous class dictionary graph where we could have lots of squares with dierent heights and widths.

To motivate the above design guideline, we derive a class dictionary for rectangles, squares, ellipses, and circles. A rst solution is to build a conceptual model such as:

Figure: Rectangle | Ellipse.

Rectangle : Square *common*

<height> DemNumber

<width> DemNumber.

Ellipse : Circle *common*

<semiaxis_height> DemNumber

<semiaxis_width> DemNumber.

Square = . Circle = .

This class dictionary denes only square and circle objects. But let's assume that we would allow alternation classes to be instantiated. We would have the following problems with the above class dictionary graph:

A square is represented by two numbers, instead of one.

We can call the functions for changing the height and the width of a square to any value, ignoring the constraint that they need to be equal.

The following class dictionary graph gives a conceptual model with its focus still on specialization, but it no longer assumes that alternation classes are instantiable.

A specialization-centered class dictionary graph follows.

6.6. CLASSDICTIONARYGRAPHDESIGN 159

Figure: Rectangular | Elliptic.

Rectangular : Rectangle | Square *common*

<height> Measure

<width> Measure.

Rectangle = . Square = .

Elliptic : Ellipse | Circle *common*

<semiaxis_height> Measure

<semiaxis_width> Measure.

Ellipse = . Circle = .

Measure = <v> DemNumber.

But we still have the two problems mentioned above. However, in this class dictionary graph Square is no longer a subclass of Rectangle, which will make it easier to improve the solution. The class dictionary graph was obtained from the previous class dictionary graph by following the rule that alternation classes cannot be instantiated. This rule implies the extra classes Rectangular and Elliptic. These classes allow us to deal with the classes Rectangleand Square separately. On the other hand, a square is no longer represented as a special kind of rectangle; we only say that a square is a special kind of rectangular object.

Now let's improve the solution and eliminate these two problems. We develop a part-centered class dictionary graph.

This class dictionary denes square, circle, rectangle, and ellipse objects. It also provides a conceptual model as did the rst one, but the focus is on representing objects with the appropriate parts and not on specializing classes. For example, Square is no longer a subclass of Rectangle.

Which class dictionary graph is better, the part-centered class dictionary graph or the specialization-centered class dictionary graph? The part-centered class dictionary graph tends to be better (because of the above two problems). Let's compute the area of a Figure-object.

For the part-centered class dictionary graph we get the program

160 ^{CHAPTER 6. CLASSDICTIONARY GRAPHSANDOBJECTS}

// compute area of any of the 4 figures

// simulating multiple inheritance with wrappers // A circle inherits code for two reasons:

// its area is determined by one side // its area is computed using PI

*operation* float area()

*init* (@ 1.0 @)

*traverse* *from* Figure *to* Measure

*wrapper* Measure

*prefix*

(@ return_val = return_val * *v; @)

// order of the following wrappers is important:

// first we need to square, then to multiply by PI

*wrapper* {Circle, Square}

*suffix*

(@ return_val = return_val * return_val; @)

*wrapper* {Circle, Ellipse}

*suffix*

(@ float PI = 3.1415; return_val = return_val * PI; @)

It is interesting to notice that the preceding propagation pattern also works for the specialization centered class dictionary graph if we delete the wrapper for circle and square.

The propagation pattern uses a class set in conjunction with a wrapper. *wrapper* Circle, Squaremeans that the wrapper code will be attached to both classes.

The table in Fig. 6.17 compares part-centered and specialization-centered designs.

In conclusion, many conceptual models for an application domain usually exist. We can distinguish between part-centered and specialization-centered class dictionary graphs and we noticed that part-centered class dictionary graphs are usually better since they have less duplication of parts and their programs can be better checked at compile-time.

We noticed that the transition from a specialization-centered program to the part-centered program is easy. Especially when the program is written with propagation patterns, a changing class structure can be easily absorbed.

We propose the following informal procedure of getting to a part-centered class dictio-nary graph:

Start with traditional specialization-centered classication (assume that alternation classes are instantiable).

Implement the restriction that alternation classes are abstract. Make class-superclass relationships into sibling relationships if dierent or incompatible parts are needed.

It is interesting to mention that traditional classication hierarchies allow alternation classes to be instantiated. Another example of a specialization-centered classication is

RealN : Rational.

Rational : Integer.

Integer : Natural.

6.6. CLASSDICTIONARY GRAPHDESIGN 161

Comparison:

part-centered specialization-centered Advantages:

---less duplication more uniform algorithm easy to check

at compile time

---Disadvantages:

---less uniform algorithm run-time check for illegal objects type system allows illegal

mutation of objects

Figure 6.17: Part-centered versus specialization-centered designs The corresponding part-centered taxonomy is

RealN : Real | Rational | Integer.

Real = <v> float@C.

Rational = <n> DemNumber <d> DemNumber.

Integer = <v> DemNumber.