Software Design Patterns

The design pattern (English pattern) is a solution to the recurring problems in object-oriented design. The term was introduced into computer science in the 1990 's by people such as Erich Gamma and others from the field of architectural design. The meaning of the term is also controversial. The algorithm is not a design pattern because the algorithm is dedicated to solving problems rather than design problems. Design patterns typically describe a set of closely interacting classes and objects. Design patterns provide a common language for discussing software design, making the design experience of skilled designers available to beginners and other designers. Design patterns also provide a goal for software refactoring.

With the growing interest in design patterns in the software development community, a number of relevant monographs have been published and regular workshops have been held, and Ward Cunningham has invented WikiWiki's experience in exchanging design patterns.

Foldededit this paragraph history

In 1987, Kent Beck and Ward Cunningham developed design patterns using Christopher Alexander's ideas in the field of architectural design and applied this idea to the generation of graphical user interfaces in Smalltalk. A year later, Erich Gamma began trying to rewrite this idea into software development in his PhD dissertation at the University of Zurich. At the same time, James Coplien from 1989 to 1991 was also using the same ideas for the development of C + +, and then in 1991 published his book Advanced C + + idioms. Just this year Erich Gamma got his doctorate and then went to America, where he collaborated with Richard Helm, Ralph Johnson, John Vlissides, and published design patterns-elements of Reusable Object-oriented software, a total of 23 design patterns are included in the book. These four authors are also known for their anonymity in the field of software development Gang of four (Gang of Four, abbreviated GOF), and their collaboration in this book has led to a breakthrough in software design patterns. Sometimes this anonymous gof will also be used to refer to the book mentioned earlier.

Foldededit this paragraph mode format

Although the name and order are different in different materials, the format of the description pattern is broadly divided into the following four main sections:

Pattern Name: Each pattern has its own name, and the name of the pattern allows us to discuss our design.

Problem (problem): In the context of object-oriented system design, it causes us to adopt a certain pattern.

Solution (Solution): The solution to the above problem, which gives the various components of the design, the relationship between them, the division of responsibilities and the way of collaboration.

Effect (consequence): the effect of the model on the other parts of the software system, such as the expansion of the system, portability. The impact also includes a negative impact.

Alias (Also known as): A pattern can have more than one name. These names should be noted in this section.

Motivation (Motivation): This pattern should be used in which cases are responsible for the scenarios provided in this section, including the issues and the ins and outs.

Application (Applicability)

Structure (Structure): This part of the common class diagram and interactive diagram illustrates this pattern.

Participant (participants): This section provides a list of the classes and objects used in this pattern, and the color of the feet they play in the design.

Cooperation (collaboration): Describes the interaction between classes and objects in this mode.

Results (Consequences): This section should describe the results, side effects, and interchanges (trade-off) after using this pattern

Implementation (Implementaion): This section should describe the implementation of the pattern, some of the schema of the pattern, the possible techniques to implement the pattern, or the proposed method of implementing the pattern.

Routine (sample Code): Demo program.

Known applications (known Uses): industry-known examples of real-doing.

Correlation mode (related Patterns): This section includes other related patterns, and differs from other similar patterns.

Foldededit Similar terms in this paragraph

A bad design that often occurs in a design and is designed to be avoided is called an anti-pattern.

FoldedMode list

Basic mode

Delegate mode

Interface mode

Proxy mode

FoldedCreate a pattern

Abstract Factory, which provides an interface for creating a series of related or interdependent objects without specifying their specific classes.

Builder mode, which separates the construction of a complex object from its representation, so that the same build process can create different representations.

Factory method Mode (Factory Methord), which defines an interface for creating objects, so that subclasses decide which class to instantiate. The Factory method defers the instantiation of a class to its subclasses.

Prototype mode (PROTOTYPE), which specifies the kind of object created with the prototype instance, and creates a new object by copying the prototype.

Singleton mode (Singleton), which guarantees that a class has only one instance, and provides a global access point to access it.

FoldedStructural mode

Adapter mode (Adapter), which transforms the interface of a class into another interface that the customer wants. The adapter mode makes it possible for those classes that would otherwise not work together because of incompatible interfaces to work together.

Bridging mode (bridge), separating the abstract part from its implementation, so that they can vary independently.

Combination mode (Composite), which combines objects into a tree structure to represent a "partial-whole" hierarchy. It enables customers to have consistent use of individual objects and composite objects.

Container mode

Modifier mode (Decorator), which dynamically adds some additional responsibilities to an object. In terms of extension functionality, it is more flexible than generating subclasses.

Extensibility Mode

Appearance mode

Enjoy meta mode

Piping and Filter modes

Proxy mode, which provides a proxy for other objects to control access to this object.

FoldedBehavioral Patterns

The responsibility chain pattern (Chain of Responsibility), which is coupled between the sender and receiver of the cancellation request, gives multiple objects an opportunity to process the request. Link the objects together and pass the request along the chain until an object handles it.

Command mode, which encapsulates a request as an object, so that you can parameterize the customer with different requests, queue requests or log requests, and support actions that can be canceled.

Curry mode

Event Listener Mode

Interpreter mode

Iterator mode

Broker mode

Memo Mode (Memento), which captures the internal state of an object without compromising encapsulation, and saves the state outside of that object. The object can then be restored to the saved state.

Observer pattern (Observer), which defines a one-to-many dependency between objects, so that when the state of an object changes, all objects that depend on it are notified and refreshed automatically.

State mode, which allows an object to change its behavior when its internal state changes. The object appears to have modified the class it belongs to.

The policy mode (strategy), defines a series of algorithms, encapsulates them one by one, and makes them interchangeable with each other. This mode allows the algorithm to be changed independently of the customer using it.

Template method Mode

The visitor pattern (Visitor), which represents an operation that acts on elements in an object structure. It allows you to define new actions that act on these elements without changing the class of each element.

Hierarchy Visitor Mode

Foldedconcurrency mode

Mode Action at a distance

Mode balking

Mode guarded suspension

Mode Scheduler

Mode Read Write lock

Mode Double checked locking

Mode Disable job requests while running job

FoldedReal-time mode

Mode Scheduled Task

Mode User Interface

Mode Disable job requests while running job

Foldedother

Model-View-Controller mode

Foldededit this paragraph mode principle

Everyone began to pay attention to design patterns. So, why do we use design patterns? Why are so many design patterns so designed? To tell the truth, I didn't know it before. is to see everyone one mouthful a "Design pattern", the heart is a bit hollow. So I bought this "gang of four" design pattern, the results can be seen indefinitely: when it seems to understand, after a while forget. May be I compare "dull" bar:) recently, have a little sentiment. "Music is better than all the music", share with you, but also hope to teach! Why advocate "Design Pattern"? The root cause is for code reuse, which increases maintainability. So how do you implement code reuse? There are several principles in OO: "open-close" principle (open Closed Principal), Richter substitution principle, and synthetic reuse principle. The design pattern is the realization of these principles, so as to achieve code reuse, increase maintainability.

FoldedOpen-Close principle

This principle is proposed by "Bertrand Meyer". The original text is: "Software entities should is open for extension,but closed for modification". This means that the module should be open for expansion and closed for modifications. The module should be extended as far as possible without modifying the original ("original", referring to the original code) code. So how do we expand it? We look at the Factory mode "factory pattern": If Zhongguancun has a sale of pirated discs and pornography of the boy, we give him a "CD sales management software." We should design a "disc" interface first. : "Pre" ______________|<>| | Disc | | _____________|| + Sell () | | || _____________| "/pre" while pirated discs and pornography are its subclasses. The kid manages these discs through "discfactory". The code is:

Some people want to buy pirated disk, how to achieve it?

public class Boy {public static void main (String "" args ") {CD-ROM D=discfactory.getdisc (" pirated disk "); Sell ();}}

If one day, this boy conscience found, began to sell genuine software. It doesn't matter, we just have to create a "CD" Subclass "Genuine software" on it. There is no need to modify the original structure and code. How about that? Open for extension, close for modification. The "open-close principle" factory model is the expansion of specific products, and some projects may require more extensibility, and to expand the "factory", it becomes the "abstract factory model."

Foldedprinciple of substitution on the Richter scale

The principle of substitution of the Richter scale is proposed by "Barbara Liskov". If the parent class is called, then a subclass can be fully run. For example: CD d=new piracy Disk (); D. Sell (); To change the "pirated disk" class to "pornography" class, no problem, can be run completely. The Java compiler checks to see if the program conforms to the Richter substitution principle. Remember a principle of Java inheritance? The subclass override method cannot have access permissions less than the parent class's corresponding method. such as "CD" in the method of "sell" access is "public", then "piracy disk" and "pornography" in the "sell" method can not be protected or private, compilation cannot pass. Why would you do that? You want to: if the "sell" method of "pirated disk" is private. Then the following code can not be executed: CD-ROM d=new piracy disk (); D. Sell (); it can be said that the principle of substitution on the Richter scale is a basis for inheritance reuse.

FoldedThe principle of synthetic multiplexing

That means less inheritance, more use of synthetic relationships to achieve. I have written this program: there are several classes to deal with the database, wrote a database operation of the class, and then other databases dealing with the classes inherit this. As a result, I modified a method of the database operations class, and each class needed to be changed. "Reaching"! Object-oriented is to limit fluctuations to a minimum range.

In Java, you should try to program for interface rather than implementing classes. This way, replacing a subclass does not affect the code that invokes it. To make each class as little as possible with others, "Don't Talk to strangers." In this way, the fire of the city gate is not implicating. Scalability and maintainability to improve

Understanding these principles, and then looking at design patterns, is just how to achieve these principles on specific issues. Zhang Mowgli Learn Taijiquan, forget all the moves, down the "Xuan Power Chou", the so-called "heart without Strokes." Design mode is a trick, if the first learning through a variety of modes, and forget all patterns and arbitrary, is the highest level of OO. Oh, funny, funny! (JR)

Dependency reversal principle abstraction should not be relied on and detail, details should depend on

FoldedDependency Reversal Principle

Programming for the interface, not for implementation. Pass parameters, or in a composite aggregation relationship, refer to the class with the highest level possible. Mainly in the construction of objects, you can dynamically create a variety of concrete objects, of course, if some concrete classes are more stable, you do not have to make an abstract class to do its parent class, so there is a sense of the tongue to add to the interface isolation principle of custom service example, each

FoldedInterface Isolation principle

A role, not a lot, do not do things, should do the work of the abstract class abstract class will not have an instance

FoldedAbstract class

A class inherits from a subclass and generally contains the common properties and methods of the system. Note: In a good inheritance relationship, only the leaf node is a concrete class, and the other nodes should be abstract classes, that is, the concrete class is not inherited. Put as much common code into the abstract class as possible. 7 Dimitri Rule minimum knowledge principle. Don't talk to strangers.

Foldededit Four elements of this paragraph

Design patterns make it easier and easier for people to reuse successful designs and architectures. The presentation of proven technologies into design patterns will also make it easier for new system developers to understand their design ideas.

Schema name

A help-person, which uses one or two words to describe the problem, solution, and effect of the pattern. Naming a new pattern adds to our design vocabulary. Design patterns allow us to design at a higher level of abstraction. Based on a pattern glossary, we can discuss patterns between ourselves and our colleagues and use them when writing documents. The pattern name helps us to think, so that we can communicate design ideas and design results to others. Finding the right model name is also one of the difficulties in cataloging our design patterns.

Problem

Describes the causes and consequences of a problem, which may describe a particular design problem, such as how to use an object representation algorithm. It may also describe a class or object structure that results in an inflexible design. Sometimes the problem section includes a series of prerequisites that the usage pattern must meet.

Solution Solutions

Describes the composition of the design, the relationship between them and their respective responsibilities and ways of collaboration. Because the pattern is like a template that can be applied to many different situations, the solution does not describe a specific and specific design or implementation, but rather provides an abstract description of the design problem and how to solve the problem with a general-meaning combination of elements (class or object combination).

Effect

It describes the effect of pattern application and the problem that the usage pattern should weigh. Although we do not always refer to pattern effects when we describe design decisions, they are important for evaluating the costs and benefits of design selection and understanding usage patterns. Most software effects focus on measuring time and space, and they also express language and implementation issues. Because reuse is one of the elements of object-oriented design, pattern effects include its impact on system flexibility, extensibility, or portability, and explicitly listing these effects is useful for understanding and evaluating these patterns.

Software Design Patterns