Amateur grass talking about design patterns

Design patterns are not completely independent, but each other, there will be some of the same shadow, let's summarize the 24 design patterns together.

Pattern Classification & Portal & Contrast Dimension description   design principles: design Pattern (master) creation type: single case mode simple Factory mode factory method pattern abstract Factory Mode Builder mode prototype mode structure: proxy mode adapter mode adorner mode Bridging mode Combo mode pattern mode behavior: Observer Mode Template Method mode Command mode state mode duty chain Mode interpreter mode Mediator mode visitor mode policy Mode Memo mode iterator Mode

The above is the classification of design patterns and the transmission door of each mode, you can see that the number of behavioral patterns is the most, the structure of the second, the creation of the least-designed mode.

In writing this article, LZ considered the most of a problem is, from which several dimensions to contrast design mode can let everyone more clearly see the differences and links between the various design patterns, reasoning, LZ decided from the following several dimensions to compare the design pattern.Design Principles: Describes which design principles each design pattern follows, and which design principles are broken.Common scenes: Describes the scenarios under which the various design patterns will appear in most cases.usage Probability: mainly refers to the frequency of the design pattern appearing in the common work, if it is included in the function provided by the class library or open source framework.Degree of complexity: In particular, the complexity of a design pattern at the time of implementation, the main criterion is the number of classes, the coupling between the classes.Change Point: A great significance of design pattern is to accommodate change, master a design pattern of the change point is very important thing.Select key Points: When choosing to use a design pattern, point out where the most critical selection is.Reverse Scales: The dragon has the reverse scale, cannot touch, the same, the design pattern also has the inverse scale, some places cannot touch.Related Design Patterns: Relationships with other design patterns.Create design pattern Single case Mode Design Principles: NoneCommon scenes: There are objects in the application that need to be global and uniqueusage Probability: 99.99999%Degree of complexity: LowChange Point: NoneSelect key Points: Whether an object can have multiple instances in the application will cause a logical or procedural errorReverse Scales: In the case of a single case, multiple instances are producedRelated Design PatternsPrototype mode: A singleton pattern is only one instance, and the prototype pattern creates a new instance each time it is copied.Simple Factory mode Design Principles: Following a single duty, violating the opening and closing principlesCommon scenes: You need to select one of the products in a bunch of productsusage Probability: 99.99999%Degree of complexity: LowChange Point: Types of productsSelect key Points: Whether a product can determine its kind according to a parameterReverse Scales: The factory class is not working properlyRelated Design PatternsFactory method Pattern: The factory method pattern is a further abstraction of the simple factory model, in which the choice between the two is mainly to see if it is necessary to further abstract the factory, and it is not necessary to use the factory method mode if the factory is used only to make the product.Factory Method Mode Design Principles: Follow a single duty, dependent inversion, open and closed principlesCommon scenes: One scenario is to keep the type of factory and product transparent to the client, to provide a consistent operation to the client, and a different factory and product that can provide clients with different services or functions.usage Probability: 60%Degree of complexity: Medium and lowChange Point: Types of factories and productsSelect key Points: Whether the factory class and the product class are the same as the relationship between the same life and deathReverse Scales: NoneRelated Design PatternsAbstract Factory Pattern: The biggest difference between the factory approach model and the abstract factory model is that in the factory method model, the factory creates a product, whereas in the abstract factory model the factory creates a product family.Abstract Factory Pattern Design Principles: Follow a single duty, dependent inversion, open and closed principlesCommon scenes: An interface is required to provide a product family without having to know the specific type of productusage Probability: 30%Degree of complexity: InChange Point: Types of factories and productsSelect key Points: Whether the product family needs to be provided together and whether there is a consistent interfaceReverse Scales: NoneRelated Design PatternsBuilder model: Both are building a group of objects or products that the difference is between the purpose and the means of implementation, in builder mode, a command is defined to reuse the object's construction process, and in abstract Factory mode, an abstract factory interface is defined in order to provide an interface for the creation of this batch of objects.Builder Model Design Principles: Follow the principle of single duty and open and closingCommon scenes: You need to build a batch of build processes that are the same but represent different products, and the build process is complexusage Probability: 10%Degree of complexity: InChange Point: The presentation of the productSelect key Points: Whether the build process is the same for each productReverse Scales: The conductor does not work properlyprototype Mode Design Principles: NoneCommon scenes: You need to dynamically create an object of the specified instance type at run time, or you need to reuse its stateusage Probability: 10%Degree of complexity: Medium and lowChange Point: NoneSelect key Points: Whether the created object can be immediately put into useReverse Scales: Deep copy not implemented in the case of a deep copyStructural Design Pattern Agent Mode Design Principles: Reflecting functional reuseCommon scenes: You need to modify or mask some of the features of one or several classes reuse another part of the function, you can use static proxy, if you need to intercept some methods in a batch of classes, insert some consistent operation before and after the method, assuming that these classes have a consistent interface, you can use the JDK dynamic proxy, otherwise you can use the Cglibusage Probability: 99.99999%Degree of complexity: Medium and highChange Point: Static proxy has no change point, dynamic proxy change point for the class with the same pointcutSelect key Points: The key point of static proxy selection is whether to reuse part of the function of the agent, the key point of dynamic proxy selection is whether we can find the same cut-in point in the class of the agent.Reverse Scales: The instability of the entry pointRelated Design PatternsAdapter mode: For custom adapters in adapter mode, it has a similar part to static proxies, both of which have the function of reusing functions, but the static agents modify some of the original functions, and the adapters are often reused, and the adapter also applies the reused classes to an interface while reusing.Adapter Mode Design Principles: Follow the opening and closing principles, reflect the function of reuseCommon scenes: You need to use the functionality of a class, but the interface of the class does not meet the requirements of the interface, you can use a custom adapter, or there is an interface definition of too much behavior, you can define a default adapter, so that subclasses selectively override the adapter's methodusage Probability: 40%Degree of complexity: InChange Point: NoneSelect key Points: The key to choosing a custom adapter is whether there is a better alternative, and the default adapter choice is whether the method in the interface is not fully available and has a default schemeReverse Scales: NoneRelated Design PatternsAdorner mode: For adapter mode in the custom adapter and adorner mode, both are the use of combination plus inheritance, the difference is that the adapter mode is designed to fit the interface, the adorner mode is to dynamically add functionality, and can be superimposed.Adorner mode Design Principles: Follow Dimitri, single duty, open and close principle, destroy the Richter replacement, reflect the functional reuseCommon scenes: A class requires dynamic add functionality, and these functions can be superimposed on each otherusage Probability: 99.99999%Degree of complexity: InChange Point: Dynamically added features or adorners.Select key Points: Whether the added functionality requires dynamic assemblyReverse Scales: NoneBridging Mode Design Principles: Follow the principle of single duty, Dimitri, opening and closing, embodying function reuseCommon scenes: An object has multiple dimension changes that need to be drawn out of the dimension to allow it to change independentlyusage Probability: 20%Degree of complexity: Medium and highChange Point: expansion and increase of dimensionsSelect key Points: Whether you can split an object into multiple unrelated dimensionsReverse Scales: NoneCombination Mode Design Principles: Follow the principle of relying on inversion and opening and closing, breaking interface isolationCommon scenes: When a structure can be combined into a tree structure, and need to provide a consistent interface to the client, so that the client operations ignore simple elements and complex elementsusage Probability: 30%Degree of complexity: InChange Point: Number of nodesSelect key Points: Whether the structure of the external interface can be transformed into a tree-shaped structureReverse Scales: Structural instability or a recursive relationship between nodes in a structureenjoy meta mode Design Principles: NoneCommon scenes: Some objects with the same status are heavily reusedusage Probability: 90%Degree of complexity: InChange Point: NoneSelect key Points: Whether the shared object can extract the external stateReverse Scales: The external state is not extracted completelyappearance mode Design Principles: Follow DimitriCommon scenes: A subsystem needs to provide services externallyusage Probability: 60%Degree of complexity: InChange Point: NoneSelect key Points: Whether the subsystem needs to rely on a lot of classes to provide services externallyReverse Scales: The change of the service provided by the subsystem or the instability of the subsystem itselfRelated Design PatternsMediator pattern: Both are designed to deal with complex coupling relationships, and the appearance pattern deals with complex dependencies between classes, and the mediator pattern deals with complex interactions between objects.Behavioral Design Patterns Observer Mode Design Principles: Follow the Dimitri, opening and closing principlesCommon scenes: The need to decouple the observer from the observer or the type of observer is uncertainusage Probability: 40%Degree of complexity: InChange Point: Types and number of observersSelect key Points: Whether the Observer is a many-to-many relationship with the observed personReverse Scales: There is too much detail between the observers to rely onTemplate Method Mode Design Principles: Damage to the Richter replacement, reflecting functional reuseCommon scenes: The function of a batch of subclasses has a public algorithm skeleton that can be extractedusage Probability: 80%Degree of complexity: Medium and lowChange Point: The concrete implementation of the steps in the algorithm skeletonSelect key Points: The algorithm skeleton is solidReverse Scales: NoneCommand mode Design Principles: Follow the Dimitri, opening and closing principlesCommon scenes: The behavior of the requester and the behavior of the processor coupling too highusage Probability: 20%Degree of complexity: Medium and highChange Point: Kind of the orderSelect key Points: Does the requester need not care about the execution of the command only to know the recipientReverse Scales: Unlimited growth of the kinds of commandsRelated Design PatternsThe responsibility chain pattern: The reason that it is easy to relate the two is that both are in order to handle the request or the command, and both are to decouple the requester from the responder, but in the command mode, the client needs to know the recipient of a command, The recipient is bound to the command and sent to the caller when the command is created. The responsibility chain mode, the client does not care about the final processing of the object of the request, the client just encapsulates a request object, then to the head of the chain of responsibility, and because of this, the two ways to achieve, there is a big differenceState mode Design Principles: Follow a single duty, dependent inversion, open and closed principlesCommon scenes: An object behaves differently in multiple states, and these States can be converted to each otherusage Probability: 20%Degree of complexity: InChange Point: Kind of stateSelect key Points: Do these states often need to be converted between different dynamics at run timeReverse Scales: NoneRelated Design PatternsPolicy patterns: They are implemented in very similar ways, the policy interface and the State interface, the specific policies and the specific state, and the contexts that both have, if you look at their class diagrams, they will find almost identical, and the difference is that the state pattern often changes the state of the context in the process of processing the request, And the strategy model is only according to the different algorithms to deal with the algorithm logic, and from the actual scene, as the name suggests, state mode change is the state, the strategy mode is the strategy

  My Blog: Code Encyclopedia: www.codedq.net: www.xttblog.com; Love sharing: www.ndislwf.com or ifxvn.com. Responsibility chain mode design principles : Follow Dimitri common scenarios : A request processing requires one or several collaborations among multiple objects usage probability : 15% complexity : Medium Change point : The length and order of the processing chain Select key : For each request, each processed object needs to be processed at once. Inverse scale : none Interpreter Mode design principles : Follow a single responsibility common scenarios : One language is frequently used use probability : 0.00009% complexity : Medium High change point : Rules for language Select key : Languages that are frequently used are available in grammar for inverse scales : The rules of the language grow unchecked or the rules are very unstable