Prototype

Intent

Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.

Solution Overview

  • A client asks a prototype to clone itself.

Participants

  • Prototype (Graphic)

    • declares an interface for cloning itself.

  • ConcretePrototype (Staff, WholeNote, HalfNote)

    • implements an operation for cloning itself.

  • Client (GraphicTool)

    • creates a new object by asking a prototype to clone itself.

Classification

The Prototype design pattern is not known by another name.

分享到
Proxy

Intent

Provide a surrogate or placeholder for another object to control access to it.

Solution Overview

  • Proxy forwards requests to RealSubject when appropriate, depending on the kind of proxy.

Participants

  • Proxy (ImageProxy)
    • maintains a reference that lets the proxy access the real subject. Proxy may refer to a Subject if the RealSubject and Subject interfaces are the same.
    • provides an interface identical to Subject's so that a proxy can by substituted for the real subject.
    • controls access to the real subject and may be responsible for creating and deleting it.
    • other responsibilities depend on the kind of proxy:
      • remote proxies are responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space.
      • virtual proxies may cache additional information about the real subject so that they can postpone accessing it. For example, the ImageProxy from the Motivation caches the real image's extent.
      • protection proxies check that the caller has the access permissions required to perform a request.

  • Subject (Graphic)

    • defines the common interface for RealSubject and Proxy so that a Proxy can be used anywhere a RealSubject is expected.

  • RealSubject (Image)

    • defines the real object that the proxy represents.

Classification

The Proxy design pattern is also known as the Surrogate.

分享到
Observer

Intent

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Solution Overview

  • ConcreteSubject notifies its observers whenever a change occurs that could make its observers' state inconsistent with its own.
  • After being informed of a change in the concrete subject, a ConcreteObserver object may query the subject for information. ConcreteObserver uses this information to reconcile its state with that of the subject.

Participants

  • Subject
    • knows its observers. Any number of Observer objects may observe a subject.
    • provides an interface for attaching and detaching Observer objects.

  • Observer
    • defines an updating interface for objects that should be notified of changes in a subject.

  • ConcreteSubject

    • stores state of interest to ConcreteObserver objects.

    • sends a notification to its observers when its state changes.

  • ConcreteObserver

    • maintains a reference to a ConcreteSubject object.

    • stores state that should stay consistent with the subject's.

    • implements the Observer updating interface to keep its state consistent with the subject's.

Classification

The Observer design pattern is also known as the Dependents, and the Publish-Subscribe.

分享到
Mediator

Intent

Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

Solution Overview

  • Colleagues send and receive requests from a Mediator object. The mediator implements the cooperative behavior by routing requests between the appropriate colleague(s).

Participants

  • Mediator (DialogDirector)
    • defines an interface for communicating with Colleague objects.

  • ConcreteMediator (FontDialogDirector)
    • implements cooperative behavior by coordinating Colleague objects.
    • knows and maintains its colleagues.

  • Colleague classes (ListBox, EntryField)
    • each Colleague class knows its Mediator object.
    • each colleague communicates with its mediator whenever it would have otherwise communicated with another colleague.

Classification

The Mediator design pattern is not known by another name.

分享到
Iterator

Intent

Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

Solution Overview

  • A ConcreteIterator keeps track of the current object in the aggregate and can compute the succeeding object in the traversal.

Participants

  • Iterator
    • defines an interface for accessing and traversing elements.

  • ConcreteIterator

    • implements the Iterator interface.
    • keeps track of the current position in the traversal of the aggregate.

  • Aggregate

    • defines an interface for creating an Iterator object.

  • ConcreteAggregate
    • implements the Iterator creation interface to return an instance of the proper ConcreteIterator.

Classification

The Iterator design pattern is also known as the Cursor.

分享到
Flyweight

Intent

Use sharing to support large numbers of fine-grained objects efficiently.

Solution Overview

  • State that a flyweight needs to function must be characterized as either intrinsic or extrinsic. Intrinsic state is stored in the ConcreteFlyweight object; extrinsic state is stored or computed by Client objects. Clients pass this state to the flyweight when they invoke its operations.
  • Clients should not instantiate ConcreteFlyweights directly. Clients must obtain ConcreteFlyweight objects exclusively from the FlyweightFactory object to ensure they are shared properly.

Participants

  • Flyweight

    • declares an interface through which flyweights can receive and act on extrinsic state.

  • ConcreteFlyweight (Character)
    • implements the Flyweight interface and adds storage for intrinsic state, if any. A ConcreteFlyweight object must be sharable. Any state it stores must be intrinsic; that is, it must be independent of the ConcreteFlyweight object's context.

  • UnsharedConcreteFlyweight (Row, Column)
    • not all Flyweight subclasses need to be shared. The Flyweight interface enables sharing; it doesn't enforce it. It's common for UnsharedConcreteFlyweight objects to have ConcreteFlyweight objects as children at some level in the flyweight object structure (as the Row and Column classes have).

  • FlyweightFactory
    • creates and manages flyweight objects.
    • ensures that flyweights are shared properly. When a client requests a flyweight, the FlyweightFactory object supplies an existing instance or creates one, if none exists.

  • Client
    • maintains a reference to flyweight(s).
    • computes or stores the extrinsic state of flyweight(s).

Classification

The Flyweight design pattern is not known by another name.

分享到
Facade

Intent

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

Solution Overview

  • Clients communicate with the subsystem by sending requests to Facade, which forwards them to the appropriate subsystem object(s). Although the subsystem objects perform the actual work, the facade may have to do work of its own to translate its interface to subsystem interfaces.
  • Clients that use the facade don't have to access its subsystem objects directly.

Participants

  • Facade (Compiler)

    • knows which subsystem classes are responsible for a request.
    • delegates client requests to appropriate subsystem objects.

  • subsystem classes (Scanner, Parser, ProgramNode, etc.)

    • implement subsystem functionality.
    • handle work assigned by the Facade object.
    • have no knowledge of the facade; that is, they keep no references to it.

Classification

The Facade design pattern is not known by another name.

分享到
Factory Method

Intent

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Solution Overview

  • Creator relies on its subclasses to define the factory method so that it returns an instance of the appropriate ConcreteProduct.

Participants

  • Product (Document)

    • defines the interface of objects the factory method creates.

  • ConcreteProduct (MyDocument)

    • implements the Product interface.

  • Creator (Application)

    • declares the factory method, which returns an object of type Product. Creator may also define a default implementation of the factory method that returns a default ConcreteProduct object.
    • may call the factory method to create a Product object.

  • ConcreteCreator (MyApplication)

    • overrides the factory method to return an instance of a ConcreteProduct.

Classification

The Factory Method design pattern is also known as the Virtual Constructor.

分享到
Decorator

Intent

Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

Solution Overview

  • Decorator forwards requests to its Component object. It may optionally perform additional operations before and after forwarding the request.

Participants

  • Component (VisualComponent)
    • defines the interface for objects that can have responsibilities added to them dynamically.

  • ConcreteComponent (TextView)
    • defines an object to which additional responsibilities can be attached.

  • Decorator
    • maintains a reference to a Component object and defines an interface that conforms to Component's interface.

  • ConcreteDecorator (BorderDecorator, ScrollDecorator)
    • adds responsibilities to the component.

Classification

The Decorator design pattern is also known as the Wrapper.

分享到
Composite

Intent

Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

Solution Overview

  • Clients use the Component class interface to interact with objects in the composite structure. If the recipient is a Leaf, then the request is handled directly. If the recipient is a Composite, then it usually forwards requests to its child components, possibly performing additional operations before and/or after forwarding.

Participants

  • Component (Graphic)

    • declares the interface for objects in the composition.
    • implements default behavior for the interface common to all classes, as appropriate.
    • declares an interface for accessing and managing its child components.
    • (optional) defines an interface for accessing a component's parent in the recursive structure, and implements it if that's appropriate.

  • Leaf (Rectangle, Line, Text, etc.)

    • represents leaf objects in the composition. A leaf has no children.
    • defines behavior for primitive objects in the composition.

  • Composite (Picture)

    • defines behavior for components having children.
    • stores child components.
    • implements child-related operations in the Component interface.

  • Client

    • manipulates objects in the composition through the Component interface.

Classification

The Composite design pattern is not known by another name.

分享到