Design Patterns Flashcards
What are
Design Patterns?
Codified methods for describing design problems and their solutions.
A Design Pattern is a named problem/solution pair that can be applied in new contexts, with advice on how to apply it in novel situations and a description of it’s trade-offs
These enable the Software Engineering community to capture design knowledge in a way that enables it to be re-used.
Three Major Classes
of
Design Patterns
Creational
Structural
Behavioral
Major Design Patterns,
organized by classification
(9)
Creational Patterns
- Factory
- Singleton
- Builder
Structural Patterns
- Adapter
- Facade
- Bridge
Behavioral Patterns
- Observer
- Strategy
- Model-View-Controller
Three Creational
Design Patterns
Factory
Singleton
Builder
Three Structural
Design Patterns
Adapter
Facade
Bridge
Three Behavioral
Design Patterns
Observer (or Publish-Subscribe)
Strategy
Model-View-Controller
Creational Design Patterns:
Singleton Pattern
Basic Description
Context/Problem
We want a single instance of a class, such as a Factory that can be accessed easily
Solution
Define a static method of the class that returns the singleton.
This yields global visibility to the single instance via a static “getInstance” method of the class
Creational Design Patterns:
Builder Pattern
Basic Description
Intent
Separate the construction of a complex object from it’s representation, so that the same construction process can create different representations/configurations.
Solution/Process
Three major Objects: Client, Director and Builder
They coordinate to produce a “Product”.
The Client requests a product from the Director, the Director ‘directs’ the Builder to build various parts of the product.
- Client knows WHAT to build, not HOW
- Director knows how to call Builder based on different inputs from the Client
- Builder knows HOW to build, not WHAT
Creational Design Patterns:
Builder Pattern
Process
Solution/Process
- Client creates Director object, configures it with desired Builder object
- Director notifies Builder whenever a part of the Product should be built
- Builder handles request from director and adds parts to the product
- Client retrieves product from Builder
Creational Design Patterns:
Factory Pattern:
Basic Process of creating an object
Create an instance of “Foo”
- Client calls FooFactory.createFoo( args )
- FooFactory creates a new Foo instance
- Using the provided arguments, FooFactory sets the various properties of the Foo instance
- Foo instance is returned to the Client
Creational Design Patterns:
Factory Pattern:
How to create and access a Factory?
Create the Factory as a Singleton
Two Options for accessing:
- Pass the factory instance around as a parameter to wherever it is needed
- Or initialize the objects that need visibility with a permanent reference(global, or higher context)
Creational Design Patterns:
Factory Pattern
Basic Description
Context/Problem
Need to create specialized instances of objects. There are special considerations such as complex logic.
Desire to separate creation responsibility from the object class.
Solution
Create a “Pure Fabrication” object, called a Factory, which handles the creation of instances of the class.
Structural Design Patterns:
Adapter Pattern
Basic Description
Context/Problem
Need to resolve incompatible interfaces, or provide a stable interface to similar components with different interfaces
Solution
Convert the original interface of the component into another interface through an intermediate Adapter object. The Adapter has the interface the Client needs, and uses the existing interface to manipulate the component.
Structural Design Patterns:
Bridge Pattern
Basic Description
Context/Problem
The derivations of an abstract class must use multiple implementations, without causing an “explosion” in the number of classes
Solution
Need to decouple a set of implementations from the set of objects using them.
Define an interface for all implementations to use, and have the derivations of the abstract class use it.
Basically creates a common interface
Structural Design Patterns:
Facade
Basic Description
Context/Problem
We need a common, unified interface to a different set of implementations or interfaces, such as within a subsystem.
Solution
Define a single point of contact to the subsystem:
A “Facade” object that “Wraps” the entire subsystem.
The facade presents a single unified interface and is responsible for collaboration with the subsystem components.
Implementation and other components of the subsystem are private and can’t be seen by external components.
