Let us visit Figure 1, in Pitfall #9, the model of the Resource Rental pattern [1, 2] that tries to model the common rules that govern any renting, whether the object rented is a DVD or a car. The Figure suffers from several notable deficiencies:

Problem #1: There are dangling classes in the example. Dangling classes in UML diagrams are a clear sign that something is not right or something is very wrong. A dangling class is a class connected to one and the only one class. We have identified two of these: Payment and Type Of Resource.

Problem #2: There are a number of unresolved many-to-many relationships. As noted by several authors, a model is not complete and thorough, until all many-to-many relationships have been decomposed into two one-to-many relations. We have identified two of these: between Resource and Resource Booking, and between Resource Rental and Resource Instance.

Problem #3: This pertains to the use of accessor methods. Accessor methods are operations that have as their only purpose, to update the internal state of an object, thus violating one of the main principles of Object Oriented Design. These methods are called get and set in this pattern.

Problem #4: There are no names associated with the relationships. This is an inherent problem, because the pattern is incomplete in documentation. If the names are not there, then different interpretations of what a given link means may arise.

Problem #5: There is no real behavior associated with the classes. A big portion of the operations described in this model focus just on listing something by a given condition. For example, get Rentals By Instance() of the class Resource Instance(). This is no real behavior associated with a responsibility for that class, but only a listing provided for some other object to operate on it.

Problem #6: Customer, Resource, Type Of Resource, and Resource Instance have the same assigned responsibility, doing the same thing, get and set, and this a clear violation of the rule of abstractions

Problem #7: Resource, Type Of Resource, and Resource Instance are passive objects and they cannot get and set.

Problem #8: What are the differences between Resource and Resource Instance? There is absolutely no difference.

Problem #9: The model is missing in inheritance and aggregation.

In addition, the Figure contains a cross line between two associations.

References 

• T. Vaccare Braga et al. A Confederation of Patterns for Business resource Management.Proceedings of Pattern Language of Programs 98 (PLOP(, September 1998.

• E. Fayad, Pitfall #9: Untraceable Patterns-The Pitfall of the Pattern Systems, The Software Patterns Blog at fayadsblog.vrlsoft.com