Home Software Architecture Design Patterns
Design Patterns Summary PDF Print E-mail
Written by FemiByte   
Wednesday, 21 October 2009 12:53

Here we discuss the design patterns described in the Gang of Four book Design Patterns: Elements of Reusable Object-Oriented Software.


What they are:

Patterns in software enable reuse of well-known, tried and tested solutions to software problems. They support the use of abstractions that are above the level of individual classes and instances.
This enables systems to be built based on well defined components which can be used as building blocks for more complex systems.

Design Patterns are a class of patterns that provide a methodology for the design of software systems or relationships between them, enabling cooperation of multiple components or modules. A design pattern is a general reuable solution to a problem in software design. It is a template for a solution of a recurring problem that may occur in different domains.

Types of Design patterns and their usage:

  • Creational
  • These patterns deal with the creation of the appropriate objects for the problem domain. They outline the best way to create objects in a reusable manner.
  • Structural
  • These patterns ease the design by identifying a simple way to realize relationships between entities. They describe how objects and classes can be combined to form structures.
  • Behavioral
  • These patterns identify common communication patterns between objects and realize these patterns. They focus on the interactions between objects in a system.
Abstract Factory Provides an interface to create and return one of several families of related objects. It adds a layer of abstraction to the Factory Method pattern. TBD
Factory Method Returns one of several possible subclasses of an abstract base class based on the data supplied to it. The Connection object in the java.sql.Connection package is an example of a factory and the factory method is createStatement(). Depending on the database driver you use you get the database vendor's implementation of the Statement interface. Hence OracleStatement (oracle.jdbc.driver.OracleStatement), SybStatement (com.sybase.jdbc2.jdbc.SybStatement), DB2Statement (com.ibm.db2.jcc.DB2Statement) etc.
Builder Separates the construction of a complex object from its representation so that the same construction process can create different representations. TBD
Prototype Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. TBD
Singleton Ensure a class has only one instance, and provide a global point of access to it. TBD
Adapter Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. TBD
Bridge Decouple an abstraction from its implementation so that the two can vary independently. TBD
Composite Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. TBD
Decorator Attach additional responsibilities to an object dynamically keeping the same interface. Decorators provide a flexible alternative to subclassing for extending functionality. TBD
Facade 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. TBD
Flyweight Use sharing to support large numbers of fine-grained objects efficiently. TBD
Proxy Provide a surrogate or placeholder for another object to control access to it. TBD
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. Chain the receiving objects and pass the request along the chain until an object handles it. TBD
Command Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. TBD
Iterator Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. TBD
Mediator 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. TBD
Memento Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later. TBD
Observer Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. TBD
State Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. TBD
Strategy Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. TBD
Template Method Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure. TBD
Last Updated on Friday, 01 January 2010 22:46

joomla 1.5 stats