The 23 gof design patterns in java ,the summary


Published on

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

The 23 gof design patterns in java ,the summary

  1. 1. GOF Design Patterns, The summary by Achraf SFAXI IS System Architect Consultant SUN Certified Professional August 2006 The creational one’s specialize in abstracting the instation process. They help in isolating how objects are created, composed and represented from the rest of the system. They are five patterns defined in this category: Abstract Factory, Builder, Factory Method, Prototype, Singleton. The Abstract Factory  The Abstract Factory provides an interface for creating families of related or dependent objects without specifying their concrete classes.  When to use it ? - The system should be independent of how its products are created, composed and represented - A family of related product objects is designed to be used togetheran and we need to enforce this constraint. - We need to provide a class library of products and we want to reveal just their interfaces, not their implementations The Builder  The goal of the Builder design pattern is to separate the construction of a complex object from its representations.  When to use it ? - The algorithm for creating a complex object should be independent of the parts that make up the object and who they are assembled. - The construction process must allow different representations for the constructed object. 1
  2. 2. The Factory Method  The Factory Method defines an interface for creating an object but lets subclasses decide which class to instanciate. Factory method lets a class defer instantiation to subclasses.  When to use it ? - A class cannot anticipate the class of objects it must create. A class wants its subclasses to specify the objects it creates. The Prototype  The prototype specifies the kinds of objects to create using a prototypical instance and creates new objects by copying this prototype.  When we use it ? - The classes to instanciate are specified at runtime, for example, by dynamic loading. - We have to avoid building a class hierarchy of factories that parallels the class hierarchy of products. - Instances of a class can have only a few different combinations of state The Singleton  The singleton ensures that a class has only one instance and provides a global point of access to that class.  When to use it ? - The must be exactly one instance of a class and it must be accessible to clients from a well-known access point. The Behavioral one’s Behavioral patterns are concerned with algorithms and the assignement of responsibilities to objects. They document the patterns of objects as well as the patterns of communication between them. They are eleven patterns defined in this category : Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, strategy, Template Method and Visitor. The Chain of responsibility  Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chains the receiving objects and passes the request along the chain until an object handles it  Reduced coupling  Added flexibility in assigning responsibilities to objects.  When to use it ?  More than one object can handle a request, and the handler isn’t known. - The set of objects that can handle a request should be specified dynamically The Command  The Comand encapsulates a request as an object.  When to use it ? 2
  3. 3. - When it is necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request. - You specify queue and execute requests at different times. - You must support undo, logging or transactions The Interpreter  Given a language, defines a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.  When to use it ? - The grammar of the language is simple - Efficiency is not a critical concern The Iterator  The Iterator provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation.  When to use it ? - We want to access a collection object’s contents without exposing its internal representation. - Provide a uniform interface for traversing different structures in a collection. The Mediator  The Mediator defines an object that encapsulates how a set of objects interacts. In a complex object structure where they are many connection between objects, every object must has knowledge of the other. We can avoid this by defining a separate mediator object that is responsible for controlling and coordinating the interaction of a group of objects (like a router for a network hosts).  When to use it ? - A set of objects of objects communicates in well-defined but complex ways. - Reusing an object is difficult because it refers to and communicates with many objects The Memento  Violating encapsulation, the Memento pattern captures and externaliszes an object’s internal state so that the object can be restored to this state later.  A Memento is an object that stores a snapshot of the internal state of another object (the Momento’s originator).  When to use it ? - A snapshot of an object’s state must be saved so it can be restored to that state later - A direct interface to obtain the state would expose implementation details and break the object’s encapsulation The Observer  The Observer defines a one-to-many dependency between objects so that when one object changes state, all its dependents are automatically notified and updated.  When to use it ? 3
  4. 4. - A need to support the broadcast communication. - A change to one object requires changing others and we don’t know how many objects need to be changed. - An object should be able to notify other objects without making assumptions about who these objects are. The State  Allows an object to alter its behavior when its internal state changes. The object will appear to change its class.  When to use it ? - An object’s behavior depends on its state and it must change its behavior at runtime depending on that state. - Operations have large, multipart conditional statements that depend on the object’s state. The Strategy  The strategy pattern defines a group of classes that represent a set of possible behaviors. The functionality differs depending on the strategy (algorithm) chosen  When to use it ? - Many related classes differ only in their behavior - We need different variants of an algorithm The template Method  The Template Method defines the skeleton of an algorithm in an operation defining some steps to subclasses. The Template Method pattern lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.  A template method defines an algorithm in terms of abstract operations that subclasses override to provide concrete behavior.  When to use it ? - to implement the invariant parts of an algorithm once and leave it up to subclasses to implement the behavior that can vary The Visitor  The Visitor pattern provides a maintainable, easy way to represent an oeration to be performed on the elements of an object structure. New operations can be defined without changing the classes of the elements on which it operates.  When to use it ? - when we need to make adding new operations easy. - when the classes defining the object structure rarely change, but we often want to define new operations over thje structure. The Structural Patterns The Structural patterns are concerned with how classes and objects are composed to form larger structures. 4
  5. 5. Seven patterns are defined in this category : Adapter, Bridge, Composite, Decorator, Façade, Flyweight and Proxy. The Adapter  The Adapter design pattern defines an intermediary between two classes, converting the interface of one class so it can be used with the other. This enables classes with incompatible interfaces to work together. Let us say that it adapts a class to work with another one by making the two-classes interfaces compatible.  When to use it ? - when we need to allow one or more incompatible objects to communicate and interact - when we need to improve reusability of older functionality The Bridge  Decouples an abstraction from its implementation, so the two can vary independently.  When to use it ? - When we need to avoid a permanent binding between an abstraction and its implementation (decouple interface and implementation) - When want to have both abstractions and their implementations extensible using subclasses. The Composite  Composite pattern combines objects into tree structures to represent either the whole hierarchy or a part of the hierarchy. This recursive composition allows clients to treat individual objects and compositions of objects uniformly.  When to use it ? - when we want to represent part-whole hierarchies of objects - when we want clients to be able to ignore the difference between compositions of objects and individual objects. The Decorator  It attaches additional responsibilities to an object dynamically.  Decorators provide a flexible alternative to subclassing for extending functionality.  When to use it ? - When we want to add responsibilities ton individual objects dynamically and transparently, that is, without affecting other objects - When we want to add responsibilities that can be withdraw later - When extension by subclassing is impractical The Facade  Provide a unified interface to a set of interfaces in a subsystem. Façade defines a hieigher level interface that makes the subsystem easier to use (because we only have to deal with one interface to communicate with the subsystem).  When we use it ? - we want to provide a simple interface to a complex subsystem 5
  6. 6. - There are many dependencies between clients and the implementation classes of an abstraction. The Flyweight  It uses sharing to support a large number of fine-grained objects efficiently. The flyweight pattern uses a shared flyweight object that can be used in multiple contexts simultaneously. The flyweight has a shareable intrinsic state extrinsic state consisting of information independent of the flyweight’s context and a non shareable flyweight’s context. Client objects are responsible for passing extrinsic state to the flyweight when it needs it.  When to use it ? - When an application uses a large number of objects. - When storage cost high because of the high number of objects - When most of the objects state can be made extrinsic - When many groups of objects may be replaced by relatively few shared objects, once extrinsic state is removed. - The benefits of using the flyweight design pattern are, essentially, reducing the number of objects to handle and reducing the memory and storage requirements The Proxy  Provides a surrogate or placeholder for another object to control access to it.  When to use it ? - Whenever there is a need for a more versatile or sophisticated reference to an object than a simple pointer. If you appreciate this document make a donation to a worldwide children association or organization. I suggest the SOS association. This document has been downloaded from the space ; you can use and broadcast it for non lucrative purposes. Further information are available upon request. Si vous appréciez ce document faites un don pour le compte d’une association ou une organisation qui s’occupe des enfants. Je recommande l’association SOS. Ce document est disponible sur; son utilisation ainsi que sa propagation pour des fins non lucratives sont gratuite 6