Lecture 25th: Design Model Summary

2006.10.23 Li Jianzhong

Creation Mode

The Singleton mode solves the number of object objects. Apart from Singleton, other creation modes solve the coupling relationship brought about by new.

Factory Method, Abstract Factory, and Builder all require an additional Factory class to instantiate the "variable object", while Prototype is a Prototype (a special Factory class) to clone the "variable object ".

In the case of a "variable type", the initial design usually starts with the Factory Method. When there are more complex changes, consider refactoring to the other three Factory models (Abstract Factory, Builder, prototype ).

 

Structural Mode

The Adapter mode focuses on the conversion interface and adapts non-conforming interfaces (suitable for the old system)

The Bridge Mode focuses on separating interfaces and their implementations, and supports multidimensional changes.

The Composite mode focuses on unified interfaces and converts "one-to-many" relationships into "one-to-one" relationships.

The Decorator mode focuses on stable interfaces and extends the functions of objects on this premise.

The Facade mode focuses on simplifying interfaces and simplifying the dependency between component systems and external customer programs.

The Flyweight mode focuses on reserved interfaces and uses the sharing technology internally to optimize object storage.

Proxy mode focuses on the fake lending interface and adds an indirect layer for flexible control

 

Behavior mode

The Template Method mode encapsulates the algorithm structure and supports algorithm substep changes.

The Strategy Mode focuses on encapsulating algorithms and supports algorithm changes.

State mode focuses on encapsulation of State-related behaviors and supports State Changes

Memento mode encapsulates object state changes and supports state storage/recovery.

The Mediator mode encapsulates interaction between objects and supports object interaction changes.

Chain Of Responsibility model focuses on encapsulating Object Responsibility and supports change Of Responsibility

The Command mode encapsulates requests as objects and supports request changes.

The Iterator mode encapsulates the internal structure of the collection object and supports collection changes.

The Interpreter mode encapsulates changes in specific fields and supports frequent changes in domain issues.

The Observer mode encapsulates object notifications and supports communication object changes.

The Visitor mode focuses on encapsulating object operation changes and supports dynamically adding new operations to the class hierarchy at runtime.

 

Relationship Diagram between modes

 

Example: comprehensive application of the model

Let's take a file splitter as an example.

At the beginning, we didn't know what mode to use.

Browse

Split: Perform binary processing on the file, get the file length, and split the number, and then read the file in sequence for processing.

From the design level, such a design is very rough. Working properly does not mean a good job.

Let's assume that we have the following requirements:

1. The program has no notification. if you split a large file and the user waits for a long time and does not know what you are doing, a progress bar should be provided.

2. when sending an email, the file splitter needs to be large. We hope to automatically split the file when the email is too large, and issue a protocol file at the same time, describes the splitting steps and sequence. Then, the client obtains the split files and merges the files according to the protocol. In this way, the file splitter should be applicable to reusable components.

3. If the file size is too large, the splitter will cause the memory to soar. The problem lies in

For example, we want to split the 1g file into four parts, which means that we need to read more than 200 MB from the hard disk at a time, so that the demand for memory will soar. Therefore, the algorithm of the program must be improved.

 

Start refactoring

The first step is to separate coupling and separate the presentation layer from the business layer.

The entire algorithm is placed in the Split function. Next, the presentation layer only needs to instantiate a segmentation algorithm class.

In this way, the interface and the class library code are smoothly decoupled. In this way, the split class library can be called by applications such as Outlook as an independent dll.

 

Then we consider that the MyFileSplitter class library may change, especially the Split algorithm may change more frequently. But now our presentation layer is dependent on the logic layer, so we want to build an interface in the middle. This requires the creation mode.

The presentation layer can use the factory mode to create ISplitter instances. Here we use reflection to create instances.

In this way, the presentation layer does not directly depend on the business logic layer.

Then we will consider the progress bar, which involves the notification relationship between the object and the object, that is, the observer mode. C #'s delegated event mechanism is actually used in this mode.

Add the SplitProgressEventHandler delegate event to the ISplit interface. This is because the interface is very stable.

Add a progress bar event to the implementation method of Split files.

The presentation layer updates the progress bar based on the received notifications.

Then we can solve the memory Spike problem. We should not read too much File Content in one breath. We can read 1 MB at a time and write it into a small file after reading the specified number. In addition, we can also use multiple threads to read a large file in parallel. This is an algorithm change. Therefore, we can think of dividing the Split method and decoupling it using the Strategy mode.

In addition, we also need to write a file merge, which may use many other design modes. For example, we may also need to support file splitting and resumable data transfer on the network. These are all possible changes that need to be considered.

 

Summary of application of design patterns

The design mode is based on the system change point, where there is a change point, and where the design mode is applied.

The design pattern should be obtained in an evolutionary manner, and the changes of the system can be accurately located only after constant evolution.

It is not a pattern for patterns. A design pattern is a soft force of software design, rather than a standard. The role of the design model should not be exaggerated.

2010.11.1