Thinking in Patterns: Step 2b
So, I retrace the design steps until I come to the context in which the Bridge pattern shows up. I want to build a system that translates CAD/CAM models into an NC set to give to a machine so that the part described by the model can be built (see Figure 12-3).
Figure 12-3. High-level view of system.
Of course, I had expanded this design by noting that I could use object-oriented design techniques to have the expert system use a Model class to get its information. Model would have two versions, one for each of the CAD/CAM systems. This is shown in Figure 12-4.
Figure 12-4. The classes to generate the NC set.
Remember, I am not concerned about the design of the expert system. While interesting (and, in many ways more challenging), that design had already been worked out. My focus is on the design of the Model. I know that the Model consists of Features, as shown in Figure 12-5.[1]
[1] The differences between V1Model and V2Model present little difficulty. Therefore, I will only discuss Model in general.
Figure 12-5. The Model design.
Now, I am ready for the Bridge pattern. It is apparent that I have multiple Features (the abstraction) with multiple CAD/CAM systems (the implementations). These are the objects that set the context for the Bridge pattern.
The Bridge pattern relates the Features to the different CAD/CAM system implementations. The Feature class is the Abstraction in the Bridge pattern while the V1 and V2 systems are the Implementations. But what about the Model? Is there a Bridge pattern present here as well? Not really. I can build the Model using inheritance because the only thing about the Model that varies is the implementation that is being used. In this case, I could make derivations of the Model for each CAD/CAM system as in Figure 12-6. If I tried using a Bridge pattern for the Model, I'd get the design shown in Figure 12-7.
Figure 12-6. Using inheritance to handle the two model types.
Figure 12-7. Using the Bridge pattern to handle the two model types.
Note that I do not really have a Bridge pattern in Figure 12-7 because Model is not varying except for the implementation. In the Feature, I have different types of Features that have different types of implementations—a Bridge pattern does exist here.
I start implementing the Bridge pattern by using Feature as the abstraction and using V1 and V2 as the basis for the implementations. To translate the problem into the Bridge pattern, I start with the standard example of the Bridge pattern and then substitute classes into it. Figure 12-8 shows the standardized, simplified form (sometimes called the canonical form).
Figure 12-8. The canonical Bridge pattern.
In the problem, Feature maps to Abstraction. There are five different kinds of features: slot, hole, cutout, irregular, and special. The implementations are the V1 and V2 systems; I choose to name the classes responsible for these implementations V1Imp and V2Imp, respectively.
Substituting the classes into the canonical Bridge pattern gives Figure 12-9.
Figure 12-9. Applying the Bridge pattern to the problem.
In Figure 12-9, the Features are being implemented by an ImpFeature, which is either a V1Imp or a V2Imp. In this design, ImpFeature would have to have an interface that allowed for Feature to get whatever information it needed to give Model the information it requested. Thus, ImpFeature would have an interface including methods such as
getX to get the X position of Feature
getY to get the Y position of Feature
getLength to get the length of Feature
It would also have methods used by only some Features:
getEdgeType to get the type of edge of Feature
Note: Only features that need this information should call this method. Later, I will talk about how to use this contextual information to help debug the code.