The Description Class Archetype

a catalog-entry-like description. It is a collection of values that apply again and again. It also provides behavior across the collection of all things that correspond to its description. [Coad99].

Classes belonging to the Description class archetype categorize members of other archetypes based on different values of attributes. Examples include the make and model of cars, the industries to which organizations belong, whether a building is low-rise, or high-rise and so on.

The other three class archetypes cover the problem domain events and activities that our software is interested in, who participates in those events and how, where the events and activities take place, and what other things are involved. The Description class archetype describes different subsets of the parties, places, and things that are involved and sometimes different categories of Moment-Intervals too.

It is important be clear about the difference between the Description and Party-Place-Thing class archetypes. Each object of a Description class describes a set of objects that belong to some category. An object of Party-Place-Thing classes is a specific, individual, identifiable item.

The difference between a Description and a Party, Place, Thing is the difference between the general description of a particular make and model of a car (the Description) and an actual example of kind of thing being described, a particular car (the Thing) standing in someone's driveway. An airplane ticket may indicate the type of airplane (the Description) used for a flight but eventually the pilot, crew and passengers need an actual airplane (the Thing) to board. We might decide we want a beach resort vacation this year (the Description) but we have to make a booking at a particular holiday venue (the Place) that fits that description. A person may indicate the industry in which they work (the Description) but this differs from the actual organization (the Party) that employs them.

Figure 1: The Description Class Archetype

Although we tend to use words like type of and kind of to talk about Description classes we are not talking about an inheritance style relationship between a Description and the items it describes. Inheritance is a relationship between two types of item. Instead the relationship between a Description and the items it describes is similar to the relationship between a class and its instances. It is a type-instance pattern.

There are also times when we truly want to describe different types of yellow Role and pink Moment-Interval archetypes and it feels right to connect a blue Description directly to a yellow Role or pink Moment-Interval. An example is an employment Moment-Interval where there are different types of employment - full-time and part-time for instance.

Pink and Blue

Typical Responsibilities

Like all the class archetypes, the usefulness of the Description class archetype in reviewing and building object models is due to its typical responsibilities, and the lists of typical attributes, operations and associations that represent those responsibilities.

More on typical responsibilities of Description classes...

More on the typical attributes, operations and associations of Description classes..

Trade off between blue and subclassing green

When talking about description archetypes, we often find ourselves using the 'type' word. A BMW 528i is a type of car; the actual BMW 528i sat on the driveway of one my friendly TogetherSoft sales reps is an object, example, specimen or instance of that type. Surely the traditional object oriented way to represent different types is to create subclasses? There are some subtle differences and some design trade-offs to be made. Let's look at the trade-off's first.

Using a blue Description class to represent different types we can very easily create a new type in a running system by creating a new instance of our Description class and configuring its attributes accordingly. Using subclassing we need to code a new class and deploy it before we could create objects of the new type; not too bad in Java but definitely not so easy in C++.

However, blue Description classes have their limitations; if different types actually have different attributes instead of just different values of the same attributes it quickly becomes messy or over complicated to use a Description class and subclassing is usually the better option. The same is true when different types need different operations; if only the algorithm of one or two operations differ we can use the plug-in strategy described below.

To summarize: A blue Description class is useful when the objects it describes have common attributes but subsets have different default values of those attributes. However, when subsets of the described objects have differing quantities and types of attribute and operations then subclassing is the better approach. Of course, the optimum model is often a mix of the two.

The Class Archetype Formerly Known As...

One oddity I have observed a number of times is to start to call Description classes, Detail classes by mistake and start a train of thought that understandably leads to profound confusion between what is a Description and what is a party, Place, Thing. This seems strange but it has happened so often in modeling workshops that it is now no longer a surprise when it happens.

In Martin Fowler's book, Analysis Patterns, classes are split into two layers: operational and knowledge. We could color the classes in the knowledge layer blue. It would indeed seem we can connect a blue class to describe any archetype - connecting to a green is the most likely, pink is the next likeliest. In my experience, connecting directly to describe a yellow Role is much less frequent and is more often the result of dropping unnecessary classes from a more general DNC inspired model shape. However, the question of whether we are connecting to describe or connecting because we are dropping unnecessary classes is one probably best debated over a few drinks after work; the end result is much the same.