From Wiki
Jump to navigationJump to search


  • A design pattern systematically names, explains, and evaluates an important and recurring design problem and its solution.
  • They capture the intent behind a design by identifying objects, collaborations, and distributions of responsibilities.
    • They capture static and dynamic structures of successful solutions to problems.
  • Patterns support reuse of software architecture and design.
  • They give software engineers a vocabulary with which to describe their designs.
  • Patterns help to improve key quality characteristics, such as reusability, extensibility, and modularity
  • Patterns solve design problems such as:
    • Finding appropriate classes to solve a problem.
    • Determining how abstract or how concrete a class should be.
    • Specifying interfaces of classes, architectures, and binary components.
    • Specifying implementations.
    • Designing for change.
  • Patterns are not code-reuse they are experience reuse !


  • Enables the reuse of software designs.
  • Efficiently capture expert knowledge and design tradeoffs.
  • Improve developer communication - common vocabulary.
  • Improves designs - by learning from others mistakes.


  • They are often deceptively simple and therefore not considered.
  • There may be pattern overload - patterns for the sake of patterns.
  • Patterns must be validated by experience.
  • Using them is a human intensive activity.

Pattern Classification

Creational Patterns

  • For initializing and configuring collections of classes and objects.
  • e.g Factory, Builder.

Structural Patterns

  • Decoupling interface and implementation.
  • e.g. Adapter, Facade, Decorator

Behavioural Patterns

  • Dynamic interactions among collaborations of objects.
  • e.g. Visitor, Memento



  • Provide a common interface to a set of interfaces within a subsystem.
  • Defines a higher level interface to make the subsystem interfaces easier to use.


  • Provide a simplified interface.


  • Shield clients from myriad subsystem components - hence promote weak coupling between clients and subsystems.
  • Reduces number of objects clients have to deal with.
  • Using a facade promotes decoupling between the client and the subsystems.
  • Note that clients can still access the subsystems directly.
    • Clients make a choice between ease of use and fine grained control (through direct access of subsystems).


public class Compiler {
  public Compiler();
  private Node node_tree;
  private Scanner scanner;
  private Parser parser;
  private Risc_CG generator;
  public void compile() {
  • The Compiler class is a facade to various sub system interfaces (Node, Scanner, Parser, Generator) that comprise a compiler.
  • The compile() method provides a high level interface to the whole process of compiling using various subsystem interfaces.
  • Here's one more example of a HomeTheatreFacade which simplifies the operation of various subsystems of a home theatre.
public class HomeTheaterFacade {
   private Amplifier amp;
   private Tuner tuner;
   private DVDPlayer dvdPlayer;
   private Projector proj;
   private Lights lights;
   private Screen screen;

   public void watchMovie() {



  • Convert the interface of one class into another interface that clients expect.
  • An adapter would let objects work together, that otherwise wouldn't because of incompatible interfaces.


  • There is a class that provides required functionality, but does not support the interface the design needs.


  • The enumeration interface allows us to step through elements of a collection.
  • However, there is now a new Iterator interface which has more functionality.
  • What if our client's design expect enumeration interfaces, but our data structure e.g. ArrayList doesn't implement Enumerations but implements Iterator.
  • We need an adapter to convert the Iterator interface to the Enumeration interface.




  • Attach additional responsibilities to an object at run time.


  • We would like to add extra behavior to an object, not a class. Modifying the class would mean making compile time changes.
  • Inheritance is a static mechanism and cannot solve this problem.


  • Can add and remove properties at run time.
  • Can handle an arbitrary number of properties.


  • The java io package makes heavy use of decorators.
  • For e.g. we have an InputStream as an interface. There is a FileInputStream, StringBufferInputStream etc.
  • What if we wanted to filter each input stream and there were different types of filters. e.g. Buffered, Pushback, LineNumber, LowerCaseInput etc
  • Then there would be a class explosion FileInputBuffered, FileInputPushback, StringBufferLineNumber etc....
  • So we'll decorate InputStream's with a FilterInputStream decorator.
  • InputStream is the abstract component, FilterInputStream is a decorator, then the different types of filters Buffered,Pushback are concrete decorators.
  • Here's a LowerCaseInputStream decorator
public class LowerCaseInputStream extends FilterInputStream {

	protected LowerCaseInputStream(InputStream in) {
	public int read() throws IOException {
		int c =;
		return ( c == -1 ? c : Character.toLowerCase((char)c));
	public int read(byte[] b, int offset, int len) throws IOException {
		int result =, offset, len);
		for(int i=offset; i < offset + result; i++) {
			b[i] = (byte) Character.toLowerCase((char)b[i]);
		return result;

  • Here's the test code, notice how the InputStream in is being decorated with different behaviours at run-time using Composition.
public class InputTest {

	public static void main(String[] args) {
		int c;
		try {
			InputStream in = new LowerCaseInputStream(new BufferedInputStream(new StringBufferInputStream("Abc Def Xyz")));
			while((c = > 0) {
				System.out.print((char) c);
		} catch (IOException e) {




  • Compose objects into tree structures to represent part whole hierarchies.
  • Allows clients to treat individual objects and compositions of objects uniformly.


  • Drawing tools - Treat Elements and Groups of Elements in the same way. e.g. draw(), drag(), can be performed on elements as well as group of elements.
  • File Systems - Files and Folders e.g. move(), copy() etc.
  • Text Systems - Words, Sentences and Pragraphs. e.g. delete(), insert() etc.


  • Consider a restaurant Menu. A menu has a MenuItem e.g. a dish. A menu can also have sub-menus e.g. DessertMenu which can have Dessert Menu Items.
  • If we want to print a Menu, we can treat Menu and MenuItems as a single composite structure.
public abstract class MenuComponent {
   public void print() {
      throws new UnsupportedOperationException();

public class MenuItem extends MenuComponent {
     public void print() {

public class Menu extends MenuComponent {
   List<MenuComponent> menuComponents = new ArrayList<MenuComponent>();
   public void print() {
      for(MenuComponent mc  : menuComponents) {
           mc.print();  //This works recursively, if a MenuComponent is a menu.



  • To provide a surrogate or a placeholder for another object to control access to it (the another object).


  • A target object can exist in another address space or hard to access place. By providing a proxy for the object - it can stand in for the real object and make it transparent for the client.
  • The target object might be expensive to create or may take a long time. The proxy can stand in for the target until it is ready and then defer all calls to the target object.


  • The classic example is Java RMI.
  • The client calls a method on a local RMI Proxy object that forwards the call across the network to a remote object that does the actual work.
  • So the remote proxy controls access to a remote object.


  • Both the proxy and realsubject implement the subject interface, therefore clients can treat proxy just like RealSubject.
  • The proxy keeps a reference to the RealSubject, so that it can forward requests to the Subject when necessary.



  • Ensure that the class has only one instance and provide a global access point for it.
  • Why not just use statics ? Object semantics may be required, plus also singletons can be created whenever we want, whereas statics tend to get loaded whether we use them or not.


  • There are some things which you need only one instance of. e.g. ImmortalMemory in Real time Java, or maybe a system wide scheduler object.


  • See below example, the Singleton class has only one unique instance.
  • It also provides a global access point to the instance through the getInstance() method.
public class Singleton {
	private static Singleton uniqueInstance;

        private Singleton() {
	public static synchronized Singleton getInstance() {
		if(uniqueInstance == null) {
			uniqueInstance = new Singleton();
		return uniqueInstance;




  • Separate construction of a complex object from its representation.
  • One construction process can be used for several representations.


  • A reader for XML documents should be able to convert the read contents to some other representation.
  • Need to encapsulate a way a complex object is constructed from the client, hides internal representation of the product (e.g. PostScript) from the client.
  • Allows objects to be constructed in a multistep fashion.


  • In the below example, the client XMLReader has a reference to TextBuilder, an abstract builder
  • This can have many implementations e.g. PostScriptBuilder, UnicodeBuilder etc.
  • The client, XMLReader then calls build_char(),build_word() on the builder which then builds the output.
  • The XMLReader then does a getOutput() on the builder to retrieve the output.




  • Rather using a constructor, create new objects by using a prototypical instance.(via cloning).
  • For e.g. creating a new instance might be expensive or complicated.


  • Need to hide the complexity of creating an object from the client.


  • Here the ItemRegistry maintains a basic list of pre-created item objects in a registry.
  • When a client requests it to create a basic item, what it does is retrieves the basic object of the item type from the registry, clones it and returns the reference to the client.




  • Encapsulate request on an object, thereby allowing us to parameterize clients with different requests and supporting undoable operations.
  • The idea is to encapsulate method invocation.


  • Decouple the requester of a certain action from the object that actually performs the action.
  • Implementing an undo semantic, Addition of new operations on current selection.


  • Check the below examples of a method requests to a File. The method operations are encapsulated as a command object, so the invoker doesnt care about who's implementing the command.
  • Note how the command pattern makes it easy to implement undo.




  • A visitor represents an operation to be performed on the components of a class structure.
  • Allow definitions for new operations on the structure, without changing the classes. (only change the visitor instead).
  • An effective way to attach new operations to objects without changing the object.


  • Here's an example from Wikipedia.
  • In this case, the CarElement classes need not be changed when a new operation is added, for e.g. wash(). it is instead implemented in the visitor.
  • For e.g. CarElementWashVisitor will implement the methods such as visit(Wheel w), visit(Engine e) and then add some code to wash the wheel, engine etc.




  • Represent a metaclass directly in the class model.
  • Allow representation of things and sorts of things.


  • We need to represent individual objects and the type of objects (their class) as well.
  • Many languages dont allow manipulation of inbuilt metaclasses, so we need to create a pattern.


  • Here is an example of a metaclass pattern, an Aircraft is a class of which there are instances like G-BWN.
  • We also use an AircraftType as a metaclass of Aircraft. Instances of AircraftType are AirCraft classes. Note, there is no generalization between a class and it's metaclass. There is an association.


GRASP Patterns


  • GRASP stands for General Responsibility Assignment Software Patterns.
  • These patterns describe some of the fundamental principles of assigning responsibilities to objects - which is one of the hardest things to do in OO.

Information Expert

  • Assign responsibility for a certain operation to the class which has the most of necessary information, aka the information expert.

Low coupling

  • Assign responsibilities such that the coupling between classes remains low.
  • Don't assign responsibilities that will create high dependency between classes and high impact in one class when some other class changes.

High cohesion

  • Assign responsibilities such that cohesion stays high.
  • For e.g. all printing related responsibilities should stay in a single Printer class.


  • Similar to the Factory pattern.
  • An object of class A has to be created.
  • Assign class B the responsibility to create objects of class A, if
    • B aggregates A objects
    • B contains A objects
    • B records instances of A objects
    • B closely uses A objects
    • B has the initializing data that will be passed to A when it is created i.e. B is an expert
    • B is already a creator of A objects.
  • An example of class A is Employee and class B is Company. So the Company class can have the responsibility to create Employee objects.

Pure Fabrication

  • OO designs are characterized by implementing classes that represent concepts in the real world.
  • However there are situations in which assigning responsibilities to only real world classes leads to problems in terms of poor cohesion and coupling.
  • Therefore pure fabrication: made up classes, which do not exist in the real world are defined.

Indirection Pattern

  • This is a fundamental pattern that is used to ensure low coupling between objects.
  • The Indirection pattern supports low coupling (and reuse potential) between two elements by assigning the responsibility of mediation between them to an intermediate object.
  • An example of this is the introduction of a controller component for mediation between data (model) and its representation (view) in the Model-view-controller pattern.


  • If behavior varies by type (Class), who is responsible ? The type of course.
  • So the type is assigned responsibility of the behavior.
  • The implementation is done by dynamically bound polymorphic operations - the very core of OO :)

Project specific patterns

  • Many projects develop their own patterns to do certain tasks.
  • These must be documented in the GoF style.
  • This is how we handle:
    • Exceptions.
    • Logging user actions.