Actors, Roles, and Types

Actor-Role

An actor can play many roles in an organization—customer, employee, supplier, etc. Examples of actors include persons and organizations.

The Actor-Role pattern separates an actor from his/her roles:

(Note: the navigation and multiplicity shown above is typical but variable.)

Personal information should be kept with the actor, while information about responsibilities, accountabilities, affiliations, etc. should be kept with the role:

Types as Objects

We often identify class with type. But a class is much more than a type. A class specifies state and behavior, while in some applications a type merely categorizes entities. In these cases we can consider representing types as instances of a type class:

As is the case with classes, types provide factory methods as the exclusive way to creating their members. Here's a typical implementation: TypesAsObjects.java.

Multiple Types

One advantage of types as objects is that an entity can have multiple types:

Consider the nightmarish alternative in which we must introduce a class for each possible combination of quality, genre, and rating.

A-Box vs. T-Box

We can combine Actor-Role and Types-as-Objects. In this case the model has two levels: a class diagram (the T-Box) and a dependent object diagram (the  A-Box):

The great advantage of Types-as-Objects is that the T-Box can be very general, while the business-specific information occurs in the A-Box. When facts about the business change, only the A-Box needs to be changed. Because only objects are contained in the A-Box, these changes can be made dynamically. (Changing the T-Box often means more development cycles.)

When not to use types-as-objects

Using classes as types is still the preferred way to go if objects of different types have different properties or behavior. (Consider adding virtual function tables to type objects if classes aren't an option.)