Design Patterns Flashcards
Name the 13 design patterns
Structural Patterns
- Composite
- Decorator
Behavioural Patterns
- Strategy
- State
- Template Method
- Iterator
- Observer
- Visitor
- Command
Creational Patterns
- Factory Method
- Abstract Factory
- Builder
- Singleton
Strategy Pattern: Motivation and intent
Motivation
Need a way to adapt the behaviour of an algorithm at runtime
Intent Define a family of algorithms, encapsulate each one, and make them interchangeable. Lets the algorithm vary independently from the context class using it.
Strategy Pattern: Benefits and Drawbacks
Benefit:
- Favours composition over inheritance
- Allows better decoupling between behaviour and context class
Drawback:
- Increases number of objects
- Client must be aware of different strategies
Sate Pattern: Motivation and intent
This pattern allows an object to alter its behaviour when its internal state changes. The object will appear to change its class.
Template Method Pattern
Motivation
- Two different components exhibit significant similarity but no re-use of implementation
- need to remove duplicated effort following a change to common functionality
Intent - defines the skeleton of an algorithm in a method deferring some steps to sub-classes. Lets sub-class redefine certain steps of an algorithm
Iterator Pattern
Motivation
– Need to traverse items of diverse sorts of aggregate objects
(lists, arrays) in uniform manner without exposing the
internal structure of the aggregate object
Intent
– Create an iterator object that maintains a reference to one
item in the aggregate object, and methods for advancing
through the collection
Composite Pattern
Motivation
– Need a way to treat collections of objects as if they were a
single (combined) whole e.g.,
File hierarchies:
• Directories are composed of files and directories
• Printing a directory requires printing each sub-directory
Intent
– To build structures of objects in the form of trees, that
contains both individual objects and compositions of objects
as nodes
– The composite object that has the same behaviour as its
parts i.e. we can apply the same operations over both
composites and individual objects
Decorator Pattern
Motivation
- need to enhance components functionality dynamically at runtime, and use enhanced component the same as plain component
Intent
- attaches additional responsibilities to an object dynamically
- provides a flexible alternative to inheritance for extending functionality
i.e. used in Java API
Observer Pattern benefits/drawback
The observer pattern provides a design where subjects and
observers are loosely coupled
creational patterns (class and object)
Class Creational patterns use inheritance to decide the
object to be instantiated
– Factory Method Pattern
Object Creational patterns delegate the instantiation to
another object
– Abstract Factory
Factory Method Pattern: motivation and intent
Motivation
• A class ( creator ) cannot anticipate the class of
objects it must create ( product )
• Subclasses of the creator type need to create
different kinds of product objects
Intent
• The Factory Method Pattern is a creational design
pattern that that provides an interface for creating
objects in superclass, but allow sub-classes to alter
the type of objects that will be created
• The Factory Method Pattern lets a class defer
instantiation to subclasses
Factory method pros and cons
Follows the Open Closed Principle
• Avoids tight coupling between concrete products
and the client that uses these products
• Localises all creational code to one place
• Extensible, allows news products to be created
However,
• Requires extra sub-classes
• May include a dense degree of code to support the
features provided by the pattern implementation
• If the factory method needs to be able to create
multiple kinds of products, then the factory
method needs to take a parameter (possibly used
in an if-else loop …. Violation of OCP)
Abstract Factory Pattern
Motivation
• Need a way to produce families of related objects without specifying
their concrete classes
– a family of related furniture: chair, sofa, coffee table
Intent
• The Abstract Factory Method Pattern is a creational design pattern
that that provides an interface for creating families of related or
dependent objects without specifying their classes
Builder Pattern
Motivation
• A complex object that requires laborious step by step
initialisation of many fields and nested objects (composite)
– Avoid a “telescopic constructor” - one giant constructor with all
possible parameters
– overload a long constructor and create several shorter versions
with fewer parameters (they will still call the main constructor,
but pass in default values to omitted parameters)
Intent
• The Builder Pattern enables encapsulation of the construction
of a product and allows the object to be constructed in steps
– Removes the needs for a “telescopic constructor” by
building objects step by step. You use only the required
steps (skip the optional ones)
BENEFITS
The Builder pattern is flexible
– A single builder can be used to build multiple objects. The parameters
of the objects can be tweaked between object creations
Singleton pattern
Motivation
• Need to ensure that only a single instance of a class is created and made
available to the entire application e.g., access to a shared resource, such as a
database
• Ensure, additional instances cannot be created
• Provides a global access to this single instance
Intent
• A creational design pattern, that only a single instance of a class is created
and provides access to this single instance by
– Making the default constructor private.
– Creating a static creation method that will act as a constructor. This
method creates an object using the private constructor and saves it in
static variable or field. All following calls to this method return the
cached object.
commmand pattern
The command pattern is useful when:
– The invoker should be decoupled from the object handling the
invocation
– A history of requests is needed
– You need callback functionality or undo operations
• For example, applying the Command pattern to our example with
the text editor, will eliminate the need for tons
of Button subclasses
– A button object will delegate the request to a linked
command object upon receiving a click from a user. The
command will either execute an operation on its own or
delegate it to one of the business logic objects.
Pros
• Decouples classes that invoke operations from classes
that perform them
• Allows reversal (undo) of operations
• Allows deferred execution of operations
• Follows the Open/Closed Principle
Cons
• Increases overall code complexity by creating multiple
Command classes that can make your design look
cluttered
visitor
Motivation
• Need a pattern where one class/interface (Visitor)
defines a computation/operation and another
(Visitable) is responsible for providing data access
• Need a way to add new behaviour to a family of classes
without modifying the existing classes
Intent
• A behavioural design pattern that lets you define a new
operation without changing the classes of the objects
on which it operates
• Places new behaviour into a separate class, instead of
integrating into existing classes.
• Objects related to the behaviour, will not be calling it by
themselves. They will be passed as arguments to
methods of the visitor object instead.
