Problem Definition

Consider a sales system that supports a sales representative selling a certain kind of computer to end users.

Let's assume the base pieces are defined as in Table 4.1.

The sales person will sell a configuration for a computer such as that in Table 4.2.

One approach might be to model this computer system as a simple representation of an object that we can sell that contains parts that can be selected (see Figure 4.1). As I show later, this approach is extremely rigid and hampers the ability to extend the system in the future.

We want a way for the sales department to come up with a configuration from these items and to be able to select them from a list of products. In addition, as new parts are added, we want to be able to add them rapidly to our deployments.

Now let's change the implementation of the Soundboard Class to support a new type of soundcard. This requires first changing the Soundboard Class and potentially breaking any existing code (violating the Open-Closed Principle discussed earlier, or more simply, if it ain't broke, don't touch it) or creating a new class. If the change results in even a minor change to the interface (for example, adding a single new data member), this will cause a ripple effect since the Computer Class must also change. In effect, any change (no matter how small) will force a rebuild and will potentially ripple throughout the entire code base. Basically, we are generating too many classes that are far too rigid. What we need is a better way.