Design Patterns 1.6 Design for change

Here are some common causes of redesign along with the design pattern (s) that address them:

2. Creating an object by specifying a class explicitly. Specify a class in the display mode to create an object.
   1. Specifying a class name when creating an object limits you to specific implementations rather than specific interfaces.
   2. Abstract Factory (87), factory method (107), prototype (117)
4. Dependence on specific operations. Dependency on special operations

   1. When you specify a special operation for the request, the method for completing the request is fixed. To avoid sending requestsCodeWhen writing, you can easily change the method to respond to the request at the compilation or running time.

   2. Chain of responsibility (223), command (233 ).
6. Dependence on hardware and software platform. dependency on the hardware software platform
   1. The external operating system interface and Application Programming Interface (a p I) are different on different hardware and software platforms. Software dependent on a specific platform will be difficult to transplant to other platforms, and even cannot keep up with updates on the local platform. Therefore, it is important to restrict the platform relevance when designing the system.
   2. Abstract Factory (87), bridge (151 ).
8. Dependence on Object representations or implementations. Dependency on object representation or implementation
   1. If the customer depends on the internal representation, storage, location, or implementation of the object, the Customer Code may change when the object changes. This information is hidden to prevent chain effects.
   2. Abstract Factory (87), bridge (151), memento (283), proxy (207)
10. Algorithmic DependenciesAlgorithmDependency
    1. During Development and reuse, algorithms are often extended, optimized, and replaced. If an object depends on an algorithm, the object also needs to be changed when the algorithm changes. Therefore, algorithms that often change need to be isolated.
    2. Builder (97), iterator (257), Strategy (315), template method (325), visitor (331 ).
12. Tight coupling tight coupling
    1. If the classes are tightly coupled, it is difficult to reuse them separately because they depend on each other. Therefore, a single block system is generated. You cannot modify or remove a single class unless you understand the internal relationship or involve many classes. Dense mass of the entire system are hard to learn, transplant, and maintain.
    2. Loose coupling enhances the possibility of reusing a single class and the entire system is easy to understand, transplant, modify, and expand.
    3. Design Patterns use abstract coupling and system layering to facilitate decoupling.
    4. Abstract Factory (87), bridge (151), chain of responsibility (223), command (233), facade (185), mediator (273), observer (293)
14. Extending functionnality by subclassing. Function Extension by generating subclass
    1. It is not easy to use subclass to customize an object. Each new class has a fixed implementation overhead (initialization, termination, etc ). Defining a subclass requires a deep understanding of the parent class. For example, to rewrite an operation, you may need to rewrite another operation. You may also need to call inherited operations. In addition, subclass extension may result in explosive growth in the number of classes. Imagine that as long as you add a simple function, you need to add many new subclasses.
    2. The combination and special delegation of common objects can provide flexible combination behavior, making inheritance optional. The new function can combine existing objects in a new way, rather than adding existing classes to the application by defining subclass.
    3. On the other hand, it is hard to understand the design of excessive use of combinations. Many design patterns allow you to define only one subclass, and then combine its instances with an existing object to customize the function.
    4. Bridge (151), chain of responsibility (223), composite (163), decorator (175), observer (293), Strategy (315 ).
16. Inability to alter classes conveniently. The class cannot be easily modified.
    1. Sometimes you must modify a class that is not easy to modify. You may needSource codeBut not (it may be a commercial class library ). Or you may need to modify many existing classes. The Design Pattern provides the modification methods in these cases.
    2. Adapter (139), deconfigurator (175), visitor (331)