Design Patterns

1
Design Patterns
Al. I. Cuza University, Iasi, Romania
Faculty of Computer Science

• Adrian Iftene
• adiftene_at_info.uaic.ro

2
Overview

• Design patterns
• Elements
• Classification
• Singleton
• Factory
• Strategy
• Decorator
• Composite
• Iterator
• Bridge, Proxy, etc.

3
Design Patterns

• Design patterns capture solutions that have
  developed and evolved over time (GOF -
  Gang-Of-Four (because of the four authors who
  wrote it), Design Patterns Elements of Reusable
  Object-Oriented Software)
• In software engineering (or computer science), a
  design pattern is a general repeatable solution
  to a commonly occurring problem in software
  design.

4
Design Patterns Elements

• Pattern name is a handle we can use to describe a
  design problem, its solutions, and consequences
  in a word or two.
• Problem describes when to apply the pattern. It
  explains the problem and its context.
• Solution describes the elements that make up the
  design, their relationships, responsibilities,
  and collaborations.
• Consequences are the results and trade-offs of
  applying the pattern. Concerns for space, time,
  language and implementation issues. Impact on a
  system's extensibility, extensibility or
  portability should be discussed.

5
Example of (Micro) pattern

• Pattern name Initialization
• Problem It is important for some code sequence
  to be executed only once at the beginning of the
  execution of the program.
• Solution The solution is to use a static
  variable that holds information on whether or not
  the code sequence has been executed.
• Consequences The solution requires the language
  to have a static variable that can be allocated
  storage at the beginning of the execution,
  initialized prior to the execution and remain
  allocated until the program termination.

6
Design Patterns Classification

• Fundamental patterns
• Creational patterns which deal with the creation
  of objects
• Structural patterns that ease the design by
  identifying a simple way to realize relationships
  between entities.
• Behavioral patterns that identify common
  communication patterns between objects and
  realize these patterns
• Concurrency patterns

7
Fundamental patterns

• Delegation pattern an object outwardly expresses
  certain behavior but in reality delegates
  responsibility
• Functional design strives for each modular part
  of a computer program has only one responsibility
  and performs that with minimum side effects
• Interface pattern method for structuring
  programs so that they're simpler to understand
• Proxy pattern an object functions as an
  interface to another, typically more complex,
  object
• Façade pattern provides a simplified interface
  to a larger body of code, such as a class
  library.
• Composite pattern defines Composite object (e.g.
  a shape) designed as a composition of one-or-more
  similar objects (other kinds of
  shapes/geometries), all exhibiting similar
  functionality. The Composite object then exposes
  properties and methods for child objects
  manipulation as if it were a simple object.

8
Creational patterns

• Abstract factory pattern centralize decision of
  what factory to instantiate
• Factory method pattern centralize creation of an
  object of a specific type choosing one of several
  implementations
• Anonymous subroutine objects pattern
• Builder pattern separate the construction of a
  complex object from its representation so that
  the same construction process can create
  different representations
• Lazy initialization pattern tactic of delaying
  the creation of an object, the calculation of a
  value, or some other expensive process until the
  first time it is needed
• Object pool avoid expensive acquisition and
  release of resources by recycling objects that
  are no longer in use
• Prototype pattern used when the inherent cost of
  creating a new object in the standard way (e.g.,
  using the 'new' keyword) is prohibitively
  expensive for a given application
• Singleton pattern restrict instantiation of a
  class to one object

9
Structural patterns

• Adapter pattern 'adapts' one interface for a
  class into one that a client expects
• Aggregate pattern a version of the Composite
  pattern
• Bridge pattern decouple an abstraction from its
  implementation
• Composite pattern a tree structure of objects
• Container pattern create objects for the sole
  purpose of holding other objects and managing
  them
• Decorator pattern add additional functionality
  to a class at runtime
• Extensibility pattern aka. Framework - hide
  complex code behind a simple interface
• Façade pattern
• Flyweight pattern a high quantity of objects
  share a common properties object to save space
• Proxy pattern a class functioning as an
  interface to another thing
• Pipes and filters a chain of processes where the
  output of each process is the input of the next
• Private class data pattern restrict
  accessor/mutator access
• Wrapper pattern See Decorator pattern

10
Behavioral patterns

• Chain of responsibility pattern Command objects
  are handled or passed on to other objects by
  logic-containing processing objects
• Command pattern Command objects encapsulate an
  action and its parameters
• Interpreter pattern Implement a specialized
  computer language
• Iterator pattern Iterators are used to access
  the elements of an aggregate object sequentially
• Mediator pattern Provides a unified interface to
  a set of interfaces in a subsystem
• Memento pattern Provides the ability to restore
  an object to its previous state (rollback)
• Observer pattern aka Publish/Subscribe or Event
  Listener.
• State pattern A clean way for an object to
  partially change its type at runtime
• Strategy pattern Algorithms can be selected on
  the fly
• Specification pattern Recombinable Business
  logic in a boolean fashion
• Template method pattern Describes the program
  skeleton of a program
• Visitor pattern A way to separate an algorithm
  from an object
• Single-serving visitor pattern Optimise the
  implementation of a visitor
• Hierarchical visitor pattern Provide a way to
  visit every node in a hierarchical data structure
  such as a tree.

11
Concurrency patterns

• Active Object
• Balking pattern
• Double checked locking pattern
• Guarded suspension
• Leaders/followers pattern
• Monitor Object
• Read write lock pattern
• Scheduler pattern
• Thread pool pattern
• Thread-Specific Storage
• Reactor pattern

12
Singleton pattern

• In software engineering, the singleton pattern is
  a design pattern that is used to restrict
  instantiation of a class to one object.
• This is useful when exactly one object is needed
  to coordinate actions across the system.
• It is also considered an anti-pattern since it is
  often used as a euphemism for global variable

13
Singleton Implementation

• The singleton pattern is implemented by creating
  a class with a method that creates a new instance
  of the class if one does not exist.
• If an instance already exists, it simply returns
  a reference to that object.
• To make sure that the object cannot be
  instantiated any other way, the constructor is
  made either private or protected.
• Note the distinction between a simple static
  instance of a class and a singleton although a
  singleton can be implemented as a static
  instance, it can also be lazily constructed,
  requiring no memory or resources until needed.

14
Singleton Class diagram
15
Singleton Code

• class Singleton
• private
• static Singleton singleton
• Singleton ()
• public
• static Singleton instance()
• if( singleton 0 )
• singleton new Singleton()
• return singleton
• void operation()
• Singleton Singletonsingleton 0
• int main()
• Singleton singleton Singletoninstance()
• singleton-gtoperation()
• return 0

16
Factory method

• The factory method pattern is an object-oriented
  design pattern.
• Like other creational patterns, it deals with the
  problem of creating objects (products) without
  specifying the exact class of object that will be
  created.
• The factory method design pattern handles this
  problem by defining a separate method for
  creating the objects, which subclasses can then
  override to specify the derived type of product
  that will be created.
• More generally, the term factory method is often
  used to refer to any method whose main purpose is
  creation of objects.

17
Factory method Class diagram
18
Factory method Code

• class Product
• class Creator
• protected
• virtual Product factoryMethod() 0
• public
• void anOperation()
• Product product factoryMethod()
• / Do some things with the Product object.
  /
• delete product
• class ConcreteProduct public Product
• class ConcreteCreator public Creator
• protected
• virtual Product factoryMethod()
• return new ConcreteProduct()

19
Factory method Code (cont)

• int main()
• / Instantiate a Creator object. /
• Creator creator new ConcreteCreator()
• / Call the operation which uses a factory
  method. /
• creator -gt anOperation()
• / Clean-up. /
• delete creator

20
Strategy

• In computer programming, the strategy pattern is
  a particular software design pattern, whereby
  algorithms can be selected on-the-fly at runtime.
• In some programming languages, such as those
  without polymorphism, the issues addressed by
  this pattern are handled through forms of
  reflection, such as the native function pointer
  or function delegate syntax.
• The strategy pattern is useful for situations
  where it is necessary to dynamically swap the
  algorithms used in an application. The strategy
  pattern is intended to provide a means to define
  a family of algorithms, encapsulate each one as
  an object, and make them interchangeable. The
  strategy pattern lets the algorithms vary
  independently from clients that use them.

21
Strategy Class diagram
22
Strategy - Example
23
Strategy Code (Java)

• // Abstract Strategy
• class abstract class Strategy
• public abstract void algorithmInterface()
• // ConcreteStrategyA
• class class ConcreteStrategyA extends Strategy
• public void algorithmInterface()
• System.out.println("ConcreteStrategyA algorithm
  is used now")
• // ConcreteStrategyB class
• class ConcreteStrategyB extends Strategy
• public void algorithmInterface()
• System.out.println("ConcreteStrategyB algorithm
  is used now")

24
Strategy Code (Java) (cont)

• class Context
• //Default Algorithm
• private Strategy strategy new
  ConcreteStrategyA()
• public void changeStrategy(Strategy newStrategy)
• strategynewStrategy
• public void getResult()
• strategy. algorithmInterface()
• //Client
• class public class Client
• public static void main(String args)
• Context contextnew Context()
• context.getResult()
• context.changeStrategy(new ConcreteStrategyB())
• context.getResult()

25
Decorator

• In object-oriented programming, the decorator
  pattern is a design pattern that allows
  new/additional behavior to be added to an
  existing method of an object dynamically.
• The decorator pattern works by wrapping the new
  "decorator" object around the original object,
  which is typically achieved by passing the
  original object as a parameter to the constructor
  of the decorator, with the decorator implementing
  the new functionality.
• Decorators are alternatives to subclassing.
  Subclassing adds behavior at compile time whereas
  decorators provide a new behavior at runtime.

26
Decorator Class diagram
27
Decorator Motivation

• As an example, consider a window in a windowing
  system. To allow scrolling of the window's
  contents, we may wish to add horizontal or
  vertical scrollbars to it, as appropriate.
• We could create a subclass ScrollingWindow that
  provides them, or we could create a
  ScrollingWindowDecorator that merely adds this
  functionality to existing Window objects.
  (Another solution is to simply modify the
  existing Window class, but this is not always
  possible)
• Now let's assume we also wish the option to add
  borders to our windows. Again, our original
  Window class has no support. The ScrollingWindow
  subclass now poses a problem, because it has
  effectively created a new kind of window. If we
  wish to add border support to all windows, we
  must create subclasses WindowWithBorder and
  ScrollingWindowWithBorder. Obviously, this
  problem gets worse with every new feature to be
  added. For the decorator solution, we need merely
  create a new BorderedWindowDecoratorat runtime,
  we can decorate existing windows with the
  ScrollingWindowDecorator or the
  BorderedWindowDecorator or both, as we see fit.

28
Composite

• In computer science, the composite pattern is a
  design pattern "A general solution to a common
  problem in software design." Composite allows a
  group of objects to be treated in the same way as
  a single instance of an object.
• Motivation When dealing with tree-structured
  data, programmers often have to discriminate
  between a leaf-node and a branch. This makes code
  more complex, and therefore, error prone. The
  solution is an interface that allows treating
  complex and primitive objects uniformly.
• In object-oriented programming, a Composite is an
  object (e.g. a shape) designed as a composition
  of one-or-more similar objects (other kinds of
  shapes/geometries), all exhibiting similar
  functionality. This is known as a "has-a"
  relationship between objects.

29
Composite Diagram class
30
Composite Code

• using System
• using System.Collections
• namespace DesignPattern
• public class Graphic
• public virtual void Print() //Prints the
  graphic.
• public class CompositeGraphic Graphic
• private ArrayList mChildGraphics new
  ArrayList() //Collection of child graphics.
• public override void Print() //Prints the
  graphic.
• foreach (Graphic graphic in mChildGraphics)
  graphic.Print()
• //Adds the graphic to the composition.
• public void Add(Graphic graphic)
• mChildGraphics.Add(graphic)
• //Removes the graphic from the composition.
• public void Remove(Graphic graphic)
• mChildGraphics.Remove(graphic)
• public class Ellipse Graphic //Prints the
  graphic.
• public override void Print()
  Console.WriteLine("Ellipse")

31
Composite Code 2

• class Program
• static void Main(string args)
• //Initialize four ellipses
• Ellipse ellipse1 new Ellipse()
• Ellipse ellipse2 new Ellipse()
• Ellipse ellipse3 new Ellipse()
• Ellipse ellipse4 new Ellipse()
• //Initialize three composite graphics
• CompositeGraphic graphic new
  CompositeGraphic()
• CompositeGraphic graphic1 new
  CompositeGraphic()
• CompositeGraphic graphic2 new
  CompositeGraphic()
• //Composes the graphics
• graphic1.Add(ellipse1) graphic1.Add(ellipse2)
• graphic1.Add(ellipse3) graphic2.Add(ellipse4)
• graphic.Add(graphic1) graphic.Add(graphic2)
• //Prints the complete graphic (four times the
  string "Ellipse").
• graphic.Print()

32
Iterator

• In object-oriented programming, the Iterator
  pattern is a design pattern in which iterators
  are used to access the elements of an aggregate
  object sequentially without exposing its
  underlying representation. An Iterator object
  encapsulates the internal structure of how the
  iteration occurs.
• For example, a tree, linked list, hash table, and
  an array all need to be iterated with Search,
  Sort, Next. Rather than having 12 different
  methods to manage, using this Pattern you would
  need to manage only 7.

33
Iterator Class diagram
34
Iterator Code

• class Iterator
• public
• Iterator(Node position)mCurrNode(position)
• // Prefix increment
• const Iterator operator()
• if(mCurrNode 0 mCurrNode-gtmNextNode 0)
  
• throw IteratorCannotMoveToNext()
• mCurrNode mCurrNode-gtmNextNode
• return this
• // Postfix increment
• Iterator operator(int)
• Iterator tempItr this
• (this)
• return tempItr
• Node operator()
• return mCurrNode
• private
• Node mCurrNode

35
Template method

• In software engineering, the template method
  pattern is a behavioral pattern.
• A template method defines the program skeleton of
  an algorithm. The algorithm itself is made
  abstract, and the subclasses of the method
  override the abstract methods to provide concrete
  behavior.
• First a class is created that provides the basic
  steps of an algorithm design. These steps are
  implemented using abstract methods. Later on,
  subclasses change the abstract methods to
  implement real actions. Thus the general
  algorithm is saved in one place but the concrete
  steps may be changed by the subclasses.

36
Template method Class diagram
37
Template method Code

• / An abstract class that is common to several
  games in which players play against the others,
  but only one is playing at a given time. /
• abstract class Game
• private int playersCount
• abstract void initializeGame()
• abstract void makePlay(int player)
• abstract boolean endOfGame()
• abstract void printWinner()
• / A template method /
• final void playOneGame(int playersCount)
• this.playersCount playersCount
• initializeGame()
• int j 0
• while (!endOfGame())
• makePlay(j)
• j (j 1) playersCount
• printWinner()

38
Abstract Factory

• The Abstract Factory Pattern provides a way to
  encapsulate a group of individual factories that
  have a common theme. In normal usage, the client
  software would create a concrete implementation
  of the abstract factory and then use the generic
  interfaces to create the concrete objects that
  are part of the theme. The client does not know
  (nor care) about which concrete objects it gets
  from each of these internal factories since it
  uses only the generic interfaces of their
  products.
• An example of this would be an abstract factory
  class DocumentCreator that provides interfaces to
  create a number of products (eg. createLetter()
  and createResume()). The system would have any
  number of derived concrete versions of the
  DocumentCreator class like FancyDocumentCreator
  or ModernDocumentCreator, each with a different
  implementation of createLetter() and
  createResume() that would create a corresponding
  object like FancyLetter or ModernResume. Each of
  these products is derived from a simple abstract
  class like Letter or Resume of which the client
  is aware. The client would need to know how to
  handle only the abstract Letter or Resume class,
  not the specific version that it got from the
  concrete factory.
• Use of this pattern makes it possible to
  interchange concrete classes without changing the
  code that uses them, even at runtime. However,
  employment of this pattern, as with similar
  design patterns, incurs the risk of unnecessary
  complexity and extra work in the initial writing
  of code.

39
Proxy

• In its most general form, is a class functioning
  as an interface to another thing. The other thing
  could be anything a network connection, a large
  object in memory, a file, or some other resource
  that is expensive or impossible to duplicate.
• Typically one instance of the complex object is
  created, and multiple proxy objects are created,
  all of which contain a reference to the single
  original complex object. Any operations performed
  on the proxies are forwarded to the original
  object. Once all instances of the proxy are out
  of scope, the complex object's memory may be
  deallocated.
• Types of proxy pattern include
• Remote proxy
• Virtual proxy
• Copy-on-write proxy
• Protection (access) proxy
• Cache proxy
• Firewall proxy
• Synchronization proxy
• Smart reference proxy

40
Proxy Class diagram
41
Adapter

• (often referred to as the wrapper pattern or
  simply a wrapper) 'adapts' one interface for a
  class into one that a client expects. An adapter
  allows classes to work together that normally
  could not because of incompatible interfaces by
  wrapping its own interface around that of an
  already existing class.
• For instance, if multiple boolean values are
  stored as a single integer but your consumer
  requires a 'true'/'false', the adapter would be
  responsible for extracting the appropriate values
  from the integer value.
• There are two types of adapter patterns
• The Object Adapter pattern
• The Class Adapter pattern

42
Bridge

• This is Meant to "decouple an abstraction from
  its implementation so that the two can vary
  independently" (Gamma et al.). The bridge uses
  encapsulation, aggregation, and can use
  inheritance to separate responsibilities into
  different classes.
• When a class varies often, the features of
  object-oriented programming become very useful
  because changes to a program's code can be made
  easily with minimal prior knowledge about the
  program.
• The bridge pattern is useful when not only the
  class itself varies often but also what the class
  does. The class itself can be thought of as the
  abstraction and what the class can do as the
  implementation.

43
Bridge Class diagram
44
Observer

• Observe the state of an object in a program. It
  is related to the principle of implicit
  invocation.
• This pattern is mainly used to implement a
  distributed event handling system. This is a very
  interesting feature in terms of real-time
  deployment of applications.
• The essence of this pattern is that one or more
  objects (called observers or listeners) are
  registered (or register themselves) to observe an
  event which may be raised by the observed object
  (the subject). (The object which may raise an
  event generally maintains a collection of the
  observers.)

45
Observer Class diagram
46
Prototype

• This is used when the type of objects to create
  is determined by a prototypical instance, which
  is cloned to produce new objects. This pattern is
  used for example when the inherent cost of
  creating a new object in the standard way (e.g.,
  using the 'new' keyword) is prohibitively
  expensive for a given application.
• To implement the pattern, declare an abstract
  base class that specifies a pure virtual clone()
  method. Any class that needs a "polymorphic
  constructor" capability derives itself from the
  abstract base class, and implements the clone()
  operation.
• The client, instead of writing code that invokes
  the "new" operator on a hard-wired class name,
  calls the clone() method on the prototype, calls
  a factory method with a parameter designating the
  particular concrete derived class desired, or
  invokes the clone() method through some mechanism
  provided by another design pattern.

47
Prototype Class diagram
48
Model-view-controller

• In complex computer applications that present a
  large amount of data to the user, a developer
  often wishes to separate data (model) and user
  interface (view) concerns, so that changes to the
  user interface will not affect data handling, and
  that the data can be reorganized without changing
  the user interface.
• The model-view-controller solves this problem by
  decoupling data access and business logic from
  data presentation and user interaction, by
  introducing an intermediate component the
  controller.

49
Model-view-controller Description

• Model
• The domain-specific representation of the
  information on which the application operates. It
  is a common misconception that the model is
  another name for the domain layer.
• Many applications use a persistent storage
  mechanism (such as a database) to store data.
• View
• Renders the model into a form suitable for
  interaction, typically a user interface element.
• Controller
• Processes and responds to events, typically user
  actions, and may invoke changes on the model.

50
Model-view-controller Class diagram
51
Model-view-controller Functionality

• MVC is often seen in web applications, where the
  view is the actual HTML page, and the controller
  is the code which gathers dynamic data and
  generates the content within the HTML. Finally
  the model is represented by the actual content,
  usually stored in a database or XML files.
• Though MVC comes in different flavors, control
  flow generally works as follows
• The user interacts with the user interface in
  some way
• A controller handles the input event from the
  user interface
• The controller accesses the model, possibly
  updating it in a way appropriate to the user's
  action
• A view uses the model to generate an appropriate
  user interface
• The user interface waits for further user
  interactions, which begins the cycle anew.

52
Exercises

• What design pattern do you use in your work?

53

• THANK YOU!