Design Patterns

Knowledge of design patterns
is crucial for any kind of serious software development.
Let’s learn what they are, what they are good for, and
the names of, and basic ideas behind, a few of the more
popular ones.

Patterns

“Each pattern describes a problem which occurs over and over
again … and then describes the core of the solution to that problem,
in such a way that you can use this solution a million times over,
without doing it the same way twice.” — Christopher Alexander

Design Patterns for Object-Oriented Software

Design Patterns are not analysis patterns, are not descriptions
of common structures like linked lists, nore are they detailed application
or framework designs. Design Patterns are “descriptions of communicating
objects and classes that are customized to solve a general design problem
in a particular context.” — Gamma et al.

Good design patterns help make your software more flexible
and reusable.

Why study design patterns

• Experts in software architecture and design are highly paid, because
  they know how to create designs that are flexible, elegant, and
  reusable.
• You become an expert through experience, reusing solutions that worked
  for you before.
• Patterns describe solutions to design problems that occur over
  and over again.
• Patterns also record design decisions, alternatives, and trade-offs
  gained from experience.
• Once you know the pattern, many design decisions follow.
• Knowing patterns helps you get designs right faster.
• Knowing the vocabulary surrounding patterns helps communication
  between designers, and can ease the documentation effort.

Common themes in design patterns

Design patterns are used by experts to make their designs more
flexible and reusable, so in studying them you tend to see:

• decoupling of classes or objects, so something can be
  changed without changing something else. “Each design pattern lets
  some aspect of the system vary independently of other aspects,
  thereby making a system more robust to a particular kind of
  change.”
• elements in a pattern which know how to do one general thing
  very well and don’t know much about anything else.
• efforts to simplify code, to make it more readable, more
  understandable.
• a major emphasis on interfaces (“program to an interface,
  not to an implementation”), and on the distinction between
  types and classes.
• a favoring of object composition over class inheritance:
  too much inheritance leads to an explosion of the number of
  classes in a system.

Some real-world examples

• Smalltalk’s MVC uses Observer to describe the relationship
  between views and a model, Composite to describe nested
  views, and Strategy for the relationship between controllers
  and views.
• In the Java AWT, components are composites, layout managers are
  strategies, and observers are used to monitor image loading.
• Most application frameworks use factory methods to create
  the right kind of document.

The 23 patterns from the book

 
Creational
Structural
Behavioral

Class
Factory Method
Adapter (class)
Interpreter
Template Method

Object
Abstract Factory
Builder
Prototype
Singleton
Adapter (object)
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor

Patterns are for Reuse

Each pattern lets you vary some aspect of the system.

Causes of redesign and patterns that address them:

• Specifying the class of an object explicitly (Abstract Factory, Factory
  Method, Prototype)
• Hard coding requests (Command, Chain of Responsibility)
• Hardware and software platform dependencies (Abstract Factory, Bridge)
• Dependence on object representations and implementations (Abstract Factory, Memento, Bridge, Proxy)
• Algorithmic dependencies (Strategy, Builder, Iterator, Template Method, Visitor)
• Tight coupling (Facade, Mediator, Observer, Command, Abstract Factory, Bridge)
• Subclassing to extend functionality (Bridge, Composite, Decorator, Chain of Responsibility, Composite, Strategy)
• Inability to alter classes conveniently (Visitor, Decorator, Adapter)

Patterns in the Document Editor Case Study

• Composite to represent the structure of the document. Glyphs can be nested
• Strategy to allow different formatting algorithms
• Decorator to add borders, etc. to the user interface
• Abstract Factory to support multiple look-and-feel standards
• Bridge to allow it to run on multiple windowing platforms
• Command to support undo
• Iterator to traverse object structures
• Visitor to allow for adding new analytical capabilities

Start by studying the easiest patterns first

Adapter, Decorator, Composite, Observer, Template Method,
Factory Method, Abstract Factory, Strategy.

List of the Original 23 Patterns

Purpose
Design Pattern
Aspect(s) that can vary

Creational
Abstract Factory
families of product objects

Builder

how a composite object gets created

Factory Method

subclass of object that is instantiated

Prototype

class of object that is instantiated

Singleton

the sole instance of a class

Structural
Adapter
interface to an object

Bridgeimplementation of an object
Compositestructure and composition of an object
Decoratorresponsibilities of an object without subclassing
Facadeinterface to a subsystem
Flyweightstorage costs of objects
Proxyhow an object is accessed; its location

Behavioral
Chain of Responsibilityobject that can fulfill a request
Commandwhen and how a request is fulfilled
Interpretergrammar and interpretation of a language
Iteratorhow an aggregate’s elements are accessed, traversed
Mediatorhow and which objects interact with each other
Mementowhat private information is stored outside an object, and when
Observernumber of objects that depend on another object; how the dependent objects stay up to date
Statestates of an object
Strategyan algorithm
Template Methodsteps of an algorithm
Visitoroperations that can be applied to object(s) without changing their class(es)