Associations As Objects

Source: comp.object.moderated
Date: 10-Feb-99

Problem: If one object invokes methods of another object, they are said to have an "association". You can make this association into a separate object, with its own data and methods. So the model:

Becomes:

In what cases should you do that?

Richard MacDonald wrote:

One easy answer is that if the association has meaningful behavior (attributes), then it must be its own "object". (I'm going to use "instance" instead of "object" from now on.)

One very vague approach is to start with the association as not-an-instance, then try out all the navigation (behavior) options you are thinking of. Now how complicated is the code from each end? Have unreasonable couplings been introduced? If so, would they be solved by moving the behavior to the associations-as-instance?

Do you often have to iterate over the associations as a collection? In other words, are there use cases where your primary focus is the collection of associations and not the objects on either end? If so, consider associations-as-instances.

Are there constraints involved, such as 1-1, where your use cases require "shifting" objects around, e.g., creating one association means destroying another? If so, consider associations-as-instances.

Alan Cline added:

One very clear case is when A and B have a many-to-many relationship. The object X is required to map an instance of class A into an instance of class B, so that a specific object can send messages to another object. Object X is often a container of some sort, such as an iterator (A) querying a node (B) in a linklist (X).

More Info:

ICON Computing, Working with OMT - Part II: Associations and Attributes

Lorrie Boyd, Patterns of Association Objects

Martin Fowler, Kendall Scott and Ivar Jacobson, UML Distilled