This feels like the form of false-laziness that is characterized in the RDBMS world as an unwillingless to create index tables. An index table sits on a Many:Many association, and describes how pairs of objects interact.

In the case of the Employee Vs Display association, it doesn't take much to see that this is Many:Many. There are many kinds of employee, and many kinds of display. To normalise the model you need an index table. Apply the same concept to the OO world, and you get an "associative object" that, for example, knows how to display an Exempt_Employee record on a Monochrome_PDA_Display.

Of course, when both peer objects have a class hierarchy, then the associative object's class hierarchy can get interesting (pairing all the leaves can get tedious). Fortunately, Perl doesn't require us to specify every last detail of this in the type system.

--Dave.