Design Patterns Explained

Chapter 4 • A Standard Object-Oriented Solution 63
In Figure 4-3, I have added a few of the methods that are needed by
the features. Note how they differ depending upon the type of
feature. This means I do not have polymorphism across features.
This is not a problem, however, since the expert system needs to
know what type of feature it has anyway. This is because the expert
system needs different kinds of information from different types of
features.
This brings up the point that I am not so interested in polymorphism
of the features. Rather, I need the ability to plug-and-play
different CAD/CAM systems without changing the expert system.
What I am trying to do— handle multiple CAD/CAM versions transparently—
gives me several clues that this solution is not a good
one:
Redundancy amongst methods— I can easily imagine that the
methods that are making calls to the V1 system will have many
similarities between them. For example, the Vlgetx for Slot
and Vlgetx for Hole will be very similar.
Messy— This is not always a good predictor, but it is another factor
that reinforces my discomfort with the solution.
Tight coupling— This solution has tight coupling because the
features are related to each other indirectly. These relationships
manifest themselves as the likely need to modify all of the features
if the following occurs:
- A new CAD/CAM system is required.
- An existing CAD/CAM system is modified.
Low cohesion— Cohesion is fairly low since methods to perform
core functions are scattered amongst the classes.
This solution satisfies
one goal: a common
API
but contains many
challenges