23 design patterns-component collaboration (TemplateMethod-Observer / Event-Strategy)

Component collaboration

The first result after the division of modern software majors is "the division of frameworks and applications." The "component collaboration" model uses late binding to achieve loose coupling between frameworks and applications. Mode.

Template Method

Motivation

  • In the software construction process, for a certain task, it often has a stable overall operating structure, but each sub-step has a lot of changes, or due to inherent reasons (such as the relationship between the framework and application) The overall structure of the task is realized simultaneously.

  • How to respond flexibly to changes in various sub-steps or late realization needs under the premise of determining a stable operating structure?

Structured software design process

Object-oriented software design process

Early binding and late binding

Pattern definition

  • Define the skeleton (stability) of the algorithm in an operation, and delay (change) some steps into subclasses. Template Method allows subclasses to redefine (override) certain steps of the algorithm without changing (multiplexing) the structure of an algorithm. - "Design Patterns" GoF

Structure

Summary of main points

  • The Template Method pattern is a very basic design pattern that has a large number of applications in object-oriented systems. It uses the most concise mechanism (polymorphism of virtual functions) to provide flexible extension points for many application frameworks, and is the basic implementation structure of code reuse.

  • In addition to being able to respond flexibly to changes in substeps, the reverse control structure of "Don't call me, let me call you" is a typical application of Template Method.

  • In terms of specific implementation, the virtual methods called by Template Method may or may not have any implementation (abstract methods, pure virtual methods), but it is generally recommended to set them as protected methods.

Observer / Event

Easy to violate the dependency inversion principle (DIP)

Motivation

  • In the process of software construction, we need to establish a "notification dependency" for some objects-the state of an object (target object) changes, and all dependent objects (observer objects) will be notified. If such dependencies are too close, the software will not be able to resist changes well.

  • Using object-oriented technology, you can weaken this dependency and form a stable dependency. In order to achieve loose coupling of software architecture.

Pattern definition

Define a 一对多(变化)dependency relationship between objects, so that when the state of an object (Subject) changes, all objects that depend on it are notified and automatically updated.

-"Design Mode" GoF

Structure

Summary of main points

  • Using object-oriented abstraction, the Observer pattern allows us to independently change the target and the observer, so that the dependence between the two is loosely coupled.

  • When the target sends a notification, there is no need to specify an observer, and the notification (which can carry notification information as a parameter) is automatically propagated.

  • The observer decides whether to subscribe to the notification, and the target audience knows nothing about it.

  • The Observer pattern is a very common design pattern in the event-based UI framework and an important part of the MVC pattern.

Strategy

If-else's bad smell can consider strategy mode for 80% of condition judgment

Motivation

  • In the software construction process, the algorithms used by some objects may be varied and often change. If these algorithms are encoded into the objects, the objects will become very complicated; and sometimes it is a performance to support algorithms that are not used. burden.

  • How to transparently change the algorithm of an object as needed at runtime? Decoupling the algorithm from the object itself to avoid the above problems?

Pattern definition

Define a series of algorithms, encapsulate them one by one, and make them mutually compatibleReplace (change). This mode allows the algorithm to change (expand, subclass) independently of the client program (stable) that uses it.

-"Design Mode" GoF

Structure

Summary of main points

  • Strategy and its subclasses provide a series of reusable algorithms for components, so that the type can be easily switched between the various algorithms at runtime.

  • The Strategy mode provides an alternative to using conditional judgment statements. Eliminating conditional judgment statements is decoupling. Code with many conditional judgment statements usually requires Strategy mode.

  • If the Strategy object has no instance variables, then each context can share the same Strategy object, thereby saving object overhead.

Guess you like

Origin www.cnblogs.com/coderzjz/p/12688305.html