Multiplicity or No Multiplicity

This leads to an interesting issue. We were able to make our Sensors behave as though they contained many Commands, without having to modify the Sensors. There must be many other situations like this in normal software design. There must be times when you could use COMPOSITE rather than building a list or vector of objects.

In other words, the association between Sensor and Command is 1:1. We were tempted to change that association to 1:many. But instead, we found a way to get 1:many behavior without a 1:many relationship. A 1:1 relationship is much easier to understand, code, and maintain than a 1:many relationship is, so this was clearly the right design tradeoff. How many of the 1:many relationships in your current project could be 1:1 if you used COMPOSITE?

Of course, not all 1:many relationship can be reverted to 1:1 by using COMPOSITE. Only those in which every object in the list is treated identically are candidates. For example, if you maintained a list of employees and searched through that list for employees whose paydate is today, you probably shouldn't use the COMPOSITE pattern, because you wouldn't be treating all the employees identically.