CS 350 – Software Design Principles and Strategies – Chapter 14 The Open-Closed Principle Modules, methods, and classes should be open for extension, but closed for modification. In other words, design your software so you can extend its capabilities without changing what’s previously been written. i.e. The bridge allows us to extend that capabilities of a system by added new graphic systems, while not modifying the existing code. Technically, except for the factory or constructor that calls the new functionality. In practice this goal is hard to achieve, but striving for it will help with good design.

CS 350 – Software Design Principles and Strategies – Chapter 14 Design from Context Bridge pattern is a good example. Shapes in the case study use the graphic system implementations What are the requirements of the shapes? They need to be able to draw lines, circles, etc. The shapes define the needs of the drawing programs.

CS 350 – Software Design Principles and Strategies – Chapter 14 Look at the Abstract Factory You have four choices of implementation Using derived classes (Create a derivation for each set. Cumbersome, but little modification. Using a single object with switches (requires the factory to be modified a lot) Using a configuration file with switches (More flexible, but modifications still required) Use a configuration file with dynamic class loading – instantiates a class based on the name of the object in a string. Flexible because new classes and combinations can be added without modifying code. How do you pick a method? The likelihood of future variation The importance of not modifying the existing system Who controls the sets of objects to be created (us or another development group) The language being used The availability of a database or config file.

CS 350 – Software Design Principles and Strategies – Chapter 14 The principle of Encapsulating Variation A good goal is to never have a class contain two issues that are varying unless these variations are explicitly coupled to each other. Otherwise when one item varies, it is coupled to the other and you have a maintenance problem. The Bridge pattern is an excellent example of encapsulating variation. The abstract factory is another example. There are many ways to implement it. If you change your mind on how to implement it, the applications using the factory do not change, since they programmed to the factory’s public interface. The adapter encapsulates variations of interfaces so they can be used by a common interface. The author presents the case that the Façade sort of encapsulates variation, but I think he is just trying to make it fit his concepts. It really isn’t encapsulation of variation as much as a simplified interface that you could then code to.