GoF设计模式简介

                                    Introduction of Design Pattern

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. So patterns are formalized best practices that you must implement yourself in your application. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

 

 

The Genesis of Java Design Patterns

The idea of patterns and a pattern language was introduced by Christopher Alexander, a building architect as a means of applying certain solutions over and over again to the same or similar problems. He also combined these existing solutions to create new solutions to new problems. Later, Ward Cunningham and Kent Beck developed five patterns to use in interaction design and finally in 1994 Erich Gamma, Richard Helm, John Vlissides, and Ralph Johnson published the classic book Design Patterns: Elements of Reusable Object-Oriented Software, that documented patterns that has become a software industry standard.

 

We will describe how you can use patterns to help you create an architecture. Instead of using the pattern sat the object or class level, which is the custom, we will abstract them to a higher level. Initially we will focus on the Gang of Four (GoF) patterns, as described in the classic book, Design Patterns: Elements of Reusable Object-Oriented Software.

 

 

Gang of Four Patterns

The GoF patterns are categorized into three categories, as follows:

l  Creational—Support the creation of objects

l  Structural—Deal with relationships between portions of your application

l  Behavioral—Influence how state and behavior flow through the system

 

 

Creational Patterns

Creational patterns are used to support the creation of objects in a system. They allow objects to be created in a system without needing to identify a specific class type in the code, thus avoiding the need to write large, complex code to instantiate an object. Creational patterns achieve this by leveraging the subclass of the class to create the objects. This may limit the type or number of objects that can be created within a system. The Creational patterns are Abstract Factory, Builder, Factory Method, Prototype, and Singleton.

 

 

Abstract Factory Pattern

The Abstract Factory pattern provides an interface for creating a family of related or dependent objects without specifying their concrete classes. Given a set of related abstract classes, the Abstract Factory pattern provides the means to create instances of these abstract classes from a matched set of concrete subclasses. The Abstract Factory pattern is shown in the figure below:.

 

  

The Abstract Factory pattern uses an abstract class to determines the appropriate concrete class to instantiate in order to create a set of concrete products implementing a standard interface. The client only interacts with the product interfaces and the Abstract Factory class. The client never knows about the concrete construction classes provided in this pattern. This pattern is similar to the Factory Method pattern, except that it creates families of related objects.

 

Benefits

1.        Isolates the concrete classes from client

2.        Allows for exchanging product families easy

3.        Promotes consistency among products by implementing a common interface

 

When to Use

1.        When the system should be independent of how its products are created, composed, and represented.

2.        When the system needs to be configured with one of multiple families of products such as for Microsoft Windows , Linux or Apple OSX classes.

3.        When the family of related product objects are designed to be used together, and it is necessary to enforce this constraint. This is one of the key reasons for the existence of this pattern; otherwise, you could use a Factory Method.

4.        When you want to provide a class library of products and only reveal their interfaces, not their implementations.

 

 

 

Builder Pattern

The Builder pattern is used to separate the construction of a complex object from its representation in order that the same construction process can be use to create different objects. The Builder pattern allows the client object to construct a complex object by providing its type and content. The client is shielded from all the details of the object’s construction. It simplifies the creation of complex objects by defining a class that is used to build instances of another class. The Builder pattern is often used to build product that are in accordance with the composite pattern. The figure illustrates the Builder pattern.

  

The Builder pattern allows you to create the complex objects one step at a time. Other patterns can build the object in a single step.

 

Benefits

1.        It allows you to vary a product’s internal representation

2.        It isolates the code for construction and representation

3.        It gives you greater control over the construction process

 

When to Use

1.        When the algorithm for creating a complex object should be independent of both the parts that make up the object and how these parts are assembled.

2.        When the construction process must allow different representations of the constructed object.

 

 

 

 

Factory Method Pattern

The Factory Method pattern defines an interface for creating an object, but lets the subclasses determine which class to instantiate. The Factory Method allows a class to defer instantiation to subclasses. This is very is useful for constructing individual objects for a specific purpose without requiring the requestor to know the specific class being instantiated. This enables you to introduce new classes without the need to modify the code since the new class only implements the interface so it can be used by the client. The figure below shows the Factory Method pattern:

 

Benefits

1.        It eliminates the need to bind application classes into your code. The code relates only to the interface and you can work with any classes that implement the relevant interface.

2.        It enables subclasses to provide an extended version of an object, since it is more flexible to create an object inside a class than to create an object directly in the client.

 

When to Use

1.        When a class cannot anticipate the class of objects it must create.

2.        When a class wants its subclasses to specify the objects it creates.

3.        When classes delegate responsibility to one of several helper subclasses, and you want to     localize the knowledge of which helper subclass is the delegate.

 

 

Prototype Pattern

The Prototype pattern is used by an object to create objects by cloning an existing object. It does this without knowing their exact class or the details of how to create them. Instead it specifies the kinds of objects to create using a prototypical instance and then creates new objects by copying this prototype. The Prototype pattern works by giving prototypical objects to an object and then initiates the creation of objects. The object that initiates the target object creation by asking the prototypical objects to make copies of themselves. The Prototype pattern makes creating objects dynamically easier by defining classes whose objects can duplicate themselves. The Prototype pattern is shown in the figure below:

Benefits

1.        It can add and remove products at run time

2.        It specifies new objects by varying values

3.        It specifies new objects by varying structure

4.        It reduces subclasses

5.        It configures an application with classes dynamically

 

When to Use

1.        When the classes to instantiate are specified at run time by dynamic loading for example.

2.        When it’s necessary to avoid building a class hierarchy of factories paralleling the class hierarchy of products

3.        When instances of a class can have one of only a few different combinations of state

 

 

Singleton Pattern

The Singleton pattern ensures that there is only one instance of a class and that provides a global point of access to the class. It ensures that all objects using an instance of this class use the same instance. The figure below shows the Singleton pattern:

   

Benefits

1.        It controlled access to sole instance

2.        It reduces the name space

3.        It permits refinement of operations and representation

4.        It permits a variable number of instances More flexible than class operations

 

When to Use

1.        When there must be exactly one instance of a class.

 

 

Structural Patterns

Structural patterns deal with how classes and objects are composed into larger structures. Structural class patterns use inheritance in order to compose interfaces and implementations. They affect applications in a variety of ways. For example, the Adapter pattern enables two incompatible systems to communicate, and the Façade pattern enables one to present a simplified interface to a user without eliminating all the options available in the system.

 

Structural patterns allow you to create systems without the need to rewrite or customize any code. This pattern allows for a system to have enhanced reusability and robust functionality. The structural patterns are Adapter, Bridge, Composite, Decorator, Façade, Flyweight, and Proxy.

 

 

Adapter Pattern

Adapter pattern acts as an intermediary between two classes, converting the interface of one class in order that it can be used with another. This pattern enables classes with incompatible interfaces to work together. The Adapter pattern allows classes with incompatible interfaces to work together by wrapping its own interface around that of an already existing class. It provides the functionality of an interface without having to know the class used to implement that interface. The figure below illustrates the Adapter pattern:

 

Benefits

1.        It facilitates communication and interaction between two or more incompatible objects

2.        It improves the reusability of legacy functionality

 

When to Use

1.        When you want to use an existing class, and its interface does not match the interface you need.

2.        When you want to create a reusable class that cooperates with unrelated or unforeseen classes—that is, classes that don’t necessarily have compatible interfaces.

3.        When you want to use an object in an environment that expects an interface that is different from the object’s interface.

4.        When interface translation among multiple sources must occur.

 

 

Bridge Pattern

The Bridge pattern divides a complex component into two separate but related inheritance hierarchies: the functional abstraction and the internal implementation. This makes it easier to change either aspect of the component so that the two can vary independently.

 

The Bridge pattern is useful when there is a hierarchy of abstractions and a corresponding hierarchy of implementations. Rather than combining the abstractions and implementations into many distinct classes, the Bridge pattern implements the abstractions and implementations as independent classes allowing them to be combined dynamically. The figure below shows the Bridge pattern:

 

Benefits

1.        It enables you to separate the interface from the implementation

2.        It improves extensibility

3.        It hides implementation details from clients

 

When to Use

1.        When you want to avoid a permanent binding between an abstraction and its implementation.

2.        When both the abstractions and their implementations should be extensible using subclasses.

3.        When changes in the implementation of an abstraction should have no impact on clients; that is, you should not have to recompile their code.

 

 

Composite Pattern

The Composite pattern composes one-or-more similar objects such that they can be manipulated as one object. It enables you to create hierarchical tree structures of varying complexity, while also allowing every element in the structure to operate with a uniform interface. The Composite pattern combines objects into tree structures representing either the whole hierarchy or a part of the hierarchy allowing clients to treat individual objects and compositions of objects uniformly. The figure below illustrates the Composite pattern:

  

Benefits

1.        Defines class hierarchies consisting of primitive objects and composite objects

2.        Makes it easier to add new kinds of components

3.        Provides flexibility of structure and a manageable interface

 

When to Use

1.        When you want to represent the whole hierarchy or a part of the hierarchy of objects.

2.        When you want clients to be able to ignore the difference between compositions of objects and individual objects.

3.        When the structure can have any level of complexity and is dynamic.

 

 

Decorator Pattern

The Decorator pattern enables you to dynamically add or remove object functionality without changing the external appearance or function of the object. It changes the functionality of an object in a manner transparent to its clients by using an instance of a subclass of the original class to delegate operations to the original object. The Decorator pattern attaches additional responsibilities to an object dynamically to provide a flexible alternative to changing object functionality without using static inheritance. The figure below illustrates the Decorator pattern:

 

Benefits

1.        It has more flexibility than static inheritance

2.        It avoids feature-laden classes high up in the hierarchy

3.        It simplifies coding because you write a series of classes, each targeted at a specific part of the functionality, rather than coding all behavior into the object

4.        It enhances the object’s extensibility because you make changes by coding new classes

 

When to Use

1.        When you want to add responsibilities to individual objects dynamically and transparently without affecting other objects.

2.        When you want to add responsibilities to the object that you might want to change in the future.

3.        When extension by static subclassing is impractical.

 

 

Façade Pattern

The Façade pattern provides a unified interface to a group of interfaces in a subsystem. The Façade pattern defines a higher-level interface that makes the subsystem easier to use since there is only one interface instead of many. This unified interface enables an object to access the subsystem using the interface to communicate with the subsystem. The figure below illustrates the Façade pattern:

  

Benefits

1.        It provides a simple interface to a complex system without reducing the options provided by the system

2.        It shields clients from subsystem components

3.        It promotes weak coupling between the subsystem and its clients

4.        It reduces coupling between subsystems if every subsystem uses its own Façade pattern and other parts of the system use the Façade pattern to communicate with the subsystem

5.        It translates the client requests to the subsystems that can fulfill those requests

 

When to Use

1.        You want to provide a simple interface to a complex subsystem.

2.        There are many dependencies between clients and the implementation classes of an abstraction.

3.        You want to layer your subsystems.

 

 

Flyweight Pattern

The Flyweight pattern reduces the number of low-level, detailed objects within a system by sharing objects. If instances of a class that contain the same information can be used interchangeably, the Flyweight pattern allows a program to avoid the expense of multiple instances that contain the same information by sharing one instance. The figure below illustrates the Flyweight pattern.

   

Benefits

1.        It reduces in the number of objects to handle

2.        It reduces in memory and on storage devices, if the objects are persisted

 

When to Use

1.        When the application uses a large number of objects.

2.        When storage costs are high because of the quantity of objects.

3.        When the application doesn’t depend on object identity.

 

 

Proxy Pattern

The Proxy pattern provides a surrogate or placeholder object to control access to the original object. There are several types of implementations of the Proxy pattern, with the Remote proxy and Virtual proxy being the most common. The figure below illustrates the Proxy pattern.

   

Benefits

1.        It allows remote proxies to hide an object resides in a different address space.

2.        It allows virtual proxies to perform optimizations, such as creating an object on demand.

 

When to Use

1.        When you need a more versatile or sophisticated reference to an object than a simple pointer.

 

 

 

 

Behavioral Patterns

Behavioral patterns focus on algorithms and the assignments of responsibilities between objects. These patterns shape the patterns of communication and characterize complex control flow through a system. By optimizing how state and behavior are transferred and modified, you can simplify, optimize, and increase the maintainability of an application.

The Behavioral patterns are Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, and Visitor

 

Chain of Responsibility Pattern

The Chain of Responsibility pattern provides for loose coupling. It establishes a chain within a system, so that a message can either be handled at the level where it is first received, or be directed to an object that can handle it. The figure below illustrates the Chain of Responsibility pattern.
 

Benefits

1.        It reduces coupling

2.        It increases flexibility in assigning responsibilities to objects

3.        It allows a set of classes to behave as a whole, because events produced in one class can be sent on to other handler classes within the composite

 

When to Use

1.        When more than one object can handle a request, and the handler isn’t known.

2.        When you want to issue a request to one of several objects without specifying the receiver explicitly.

3.        When the set of objects that can handle a request should be specified dynamically.

 

 

Command Pattern

The Command pattern encapsulates a request in an object, which enables you to store the command, pass the command to a method, and return the command like any other object. The figure below illustrates the Command pattern.

 

Benefits

1.        It separates the object that invokes the operation from the one that knows how to perform it.

2.        It’s easy to add new commands, because you don’t have to change existing classes.

 

When to Use

1.        When you want to parameterize objects by an action to perform.

2.        When you specify, queue, and execute requests at different times.

3.        When you must support undo, logging, or transactions.

 

 

Interpreter Pattern

The Interpreter pattern interprets a language to define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language. The figure below illustrates the Interpreter pattern.

 

Benefits

1.        It’s easy to change and extend the grammar.

2.        The implementation of the grammar is easy.

 

When to Use

1.        When the grammar of the language is simple.

2.        When efficiency is not a critical concern.

 

 

Iterator Pattern

The Iterator pattern provides a consistent way to sequentially access items in a collection that is independent of and separate from the underlying collection. The figure below illustrates the Iterator pattern.

   

Benefits

1.        It supports variations in the traversal of a collection

2.        It simplifies the interface of the collection

 

When to Use

1.        When accessing collection object’s contents without exposing its internal representation

2.        When support of multiple traversals of objects in a collection

3.        In order to provide a uniform interface for traversing different structures in a collection

 

 

Mediator Pattern

The Mediator pattern simplifies communication among objects in a system by introducing a single object that manages message distribution among other objects. The Mediator pattern promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. The figure below illustrates the Mediator pattern.

 

Benefits

1.        It decouples colleagues

2.        It simplifies object protocols

3.        It centralizes control

4.        The individual components become simpler and easier to manage since they no longer need to directly pass messages to each other.

5.        Components are more generic, because they no longer need to contain logic to deal with their communication with other components.

 

When to Use

1.        When a set of objects communicate in well-defined but complex ways.

2.        When you want to customize a behavior that’s distributed between several objects without using subclasses.

 

 

Memento Pattern

The Memento pattern preserves a “snapshot” of an object’s state, so that the object can return to its original state without having to reveal its content to the rest of the world. The figure below illustrates the Memento pattern.

 

Benefits

1.        It preserves encapsulation boundaries

2.        It simplifies the originator

 

When to Use

1.        When a snapshot of an object’s state must be saved so that it can be restored to that state later.

2.        When using a direct interface to obtain the state would expose implementation details and break the object’s encapsulation.

 

 

Observer Pattern

The Observer pattern provides a way for a component to flexibly broadcast messages to interested receivers. It defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. The figure below illustrates the Observer pattern.

   

Benefits

1.        It abstracts coupling between subject and observer

2.        It supports for broadcast communication

 

 

When to Use

1.        When a change to one object requires changing the other object, and you don’t know how many objects need to change.

2.        When an object should be able to notify other objects without making assumptions about the identity of those objects.

 

 

State Pattern

The State pattern allows an object to alter its behavior when its internal state changes. The object appears to change its class. The figure below illustrates the State pattern.

   

Benefits

1.        It localizes state-specific behavior and partitions behavior for different states

2.        It makes state transitions explicit

 

When to Use

1.        When an object’s behavior depends on its state, and it must change its behavior at run-time depending on that state.

2.        When operations have large, multipart conditional statements that depend on the object’s state.

 

 

Strategy Pattern

The Strategy pattern defines a group of classes that represent a set of possible behaviors. These behaviors can then be used in an application to change its functionality. The figure below illustrates the Strategy pattern.

 

Benefits

1.        It provides an alternative to subclassing

2.        It defines each behavior in its own class, which eliminates conditional statements

3.        It’s easier to extend a model to incorporate new behaviors without recoding the application

 

When to Use

When many related classes differ only in their behavior.

When you need different variants of an algorithm.

When an algorithm uses data unknown to clients.

 

 

Template Method Pattern

The Template Method pattern provides a method that allows subclasses to override parts of the method without rewriting it. Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. The Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure. The figure below illustrates the Template Method pattern.

   

Benefits

1.        It is a fundamental technique for reusing code

 

When to Use

1.        When you want to implement the invariant parts of an algorithm once and use subclasses to implement the behavior that can vary.

2.        When common behavior among subclasses should be factored and localized in a common class to avoid code duplication.

 

 

Visitor Pattern

The Visitor pattern provides a maintainable, easy way to represent an operation to be performed on the elements of an object structure. The Visitor pattern lets you define a new operation without changing the classes of the elements on which it operates. The figure below illustrates the Visitor pattern.

   

Benefits

1.        It makes adding new operations easy

2.        It gathers related operations and separates unrelated ones

 

When to Use

1.        When an object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes.

2.        When classes defining the object structure rarely change, but you often want to define new operations over the structure.