What are Patterns?

A pattern is a proven solution to a problem in a context. Pattern must: solve a problem be related to a context be general to fit in many situations impart knowledge (information how the pattern solves the problem) have a unique name

When to Use Patterns

Solutions to problems that recur with variations No need for reuse if problem only arises in one context Solutions that require several steps: Not all problems need all steps Patterns can be overkill if solution is a simple linear set of instructions Solutions where the solver is more interested in the existence of the solution than its complete derivation Patterns leave out too much to be useful to someone who really wants to understand They can be a temporary bridge

Where They are Used

Object-Oriented programming languages [and paradigm] are more amenable to implementing design patterns Procedural languages: need to define Inheritance Polymorphism Encapsulation

Patterns in non-software domains

Name: ChocolateChipRatio Context: You are baking chocolate chip cookies in small batches for family and friends Consider these patterns first: SugarRatio, FlourRatio, EggRatio Problem: Determine the optimum ratio of chocolate chips to cookie dough Solution: Observe that most people consider chocolate to be the best part of the chocolate chip cookie. Also observe that too much chocolate may prevent the cookie from holding together, decreasing its appeal. Since you are cooking in small batches, cost is not a consideration. Therefore, use the maximum amount of chocolate chips that results in a sturdy cookie. Consider next: WalnutRatio or CookingTime or FreezingMethod

Classification
Creational Abstract Factory Structural Adapter Behavioral Chain of Responsibility Command Interpreter Observer

Builder Factory Method

Bridge Composite

State Strategy

Prototype

Decorator

Iterator

Template Method

Singleton

Facade

Mediator

Visitor

Flyweight
Proxy

Memento

Intent

OBSERVER

define a one-to-many dependency between objects so that when one object changes state, all dependents are notified & updated.

Structure

Known Uses
Smalltalk Model-View-Controller (MVC) InterViews (Subjects & Views, Observer/Observable) Pub/sub middleware (e.g., CORBA Notification Service, Java Message Service) Mailing lists

COMPOSITE
Intent
treat individual objects & multiple, recursively-composed objects uniformly

Structure

Known Uses
ET++ Vobjects InterViews Glyphs, Styles Unidraw Components, MacroCommands Directory structures on UNIX & Windows MIME types in SOAP

STRATEGY
Intent
define a family of algorithms, encapsulate each one, & make them interchangeable to let clients & algorithms vary independently

Structure

Known Uses
InterViews text formatting RTL register allocation & scheduling strategies ET++SwapsManager calculation engines The ACE ORB (TAO) Real-time CORBA middleware

DECORATOR
Intent
Transparently augment objects with new responsibilities dynamically

Structure

Known Uses

embellishment objects from most OO-GUI toolkits ParcPlace PassivityWrapper InterViews DebuggingGlyph Java I/O classes

ABSTRACT FACTORY
Intent
create families of related objects without specifying subclass names

Structure

Known Uses
InterViews Kits ET++ WindowSystem AWT Toolkit The ACE ORB (TAO)

BRIDGE
Intent
separate a (logical) abstraction interface from its (physical) implementation(s)

Structure

Known Uses
ET++ Window/WindowPort libg++ Set/{LinkedList, HashTable} AWT Component/ComponentPeer

COMMAND
Intent
encapsulate the request for a service

Structure

Known Uses
InterViews Actions MacApp, Unidraw Commands JDKs UndoableEdit, AccessibleAction Emacs

ITERATOR
Intent
access elements of a container without exposing its representation

Structure

Known Uses
C++ STL iterators JDK Enumeration, Iterator Unidraw Iterator

VISITOR
Intent
centralize operations on an object structure so that they can vary independently but still behave polymorphically

Structure

Known Uses
ProgramNodeEnumerator in Smalltalk-80 compiler IRIS Inventor scene rendering TAO IDL compiler to handle different backends

Advantages:
Enable large scale reuse of S/W.
They Helps in improve developer communication. Capture expert knowledge and design trade-offs and make expertise widely available

Disadvantages:
Do not lead to direct code reuse and Complex in nature. They are validated by experience and discussion. They consume more memory because of generalized format. They are written, to store any kind of data, make performance degrade.