Design Patterns

1
Design Patterns
2
Agenda

• Good practices again
• Pattern - what is it ?
• Definition, explanation, examples
• Classifications
• Which aspect of design is easy to change by
  pattern?
• Review of patterns (GoF)

3
Good practices

• Programming to interface not to implementation.
  Client should always call the abstraction
  (interface) and not the exact implementation.
• Type interface contract
• Implementation class
• Have loose coupling. Use rather aggregation than
  inheritance
• delegations

4
Pattern definition ?

• Patterns provide simple, elegant solutions to
  recurring design problems.
• Name for collecting advices and knowledge about
  problem and its solutions.
• Changing view from code reuse to knowledge reuse
• Shorthand to conclusions about common design
  problems and techniques

5
Template method

• Pattern
• Define the skeleton of an algorithm in an
  operation, deferring some steps to subclasses.
  Template Method lets subclasses redefine certain
  steps of an algorithm without changing the
  algorithm's structure.

6
Template method
7
Template method

• Participants and cooperation AbstractClass  (Data
  Object)
• defines abstract primitive operations that
  concrete subclasses define to implement steps of
  an algorithm
• implements a template method defining the
  skeleton of an algorithm. The template method
  calls primitive operations as well as operations
  defined in AbstractClass or those of other
  objects.
• ConcreteClass  (CustomerDataObject)
• implements the primitive operations to carry out
  subclass-specific steps of the algorithm

8
Template method - example
Print(StreamWriter dst) PrintHeader(dst)
PrintBody(dst) PrintFooter(dst)
9
Template method

• When
• - When can separate fixed part / variations of
  algorithms
• - Common behavior can/should be separated and
  placed in base class
• Consequences
• Behavior of class has to be determined in the
  compilation time cannot be changed in the
  rune-time
• We can define simply/default implementations in a
  base class or not
• The access to primitives can be limited by
  protected accessor
• Implementation remarks
• Possible access limitation
• The number of primitive operations should be
  rater kept on relatively low level
  combinatorial explosion
• Known/common use cases
• Most of abstract classes
• Related patterns
• Strategy

10
Strategy (alias Policy)

• Pattern
• Define a family of algorithms, encapsulate each
  one, and make them interchangeable.

11
Strategy
12
Strategy - example
... val calc.CalculateTotal(...) ...
13
Strategy

• When
• We need many, similar variants of a particular
  algorithm
• We need to hide details of algorithm (e.g.
  additional parameters)
• There are many conditional behaviors many
  switches/conditionals are used in multiple places
• Consequences
• Behavior as well as implementation can be changed
  in the rune-time
• Good alternative for multiple if blocks - we can
  simply once choose a particular implementation of
  behavior
• No necessity to define many subclasses
• We can create the families of connected
  algorithms
• Context has to know about multiple strategies or
  has to be parametrized with a strategy
• Increased number of objects
• Implementation
• Interfaces, strategies as template parameters
• If object of strategy is optional the Context may
  be much simpler
• Related patterns
• Template method
• Flyweight

14
What is important

• Pattern is not a ready to use library but rather
  a way with some knowledge about an end of the
  way. Usually there are many ways to implement a
  particular pattern.
• Learning about patterns means more than
  memorizing pattern names and the mechanics of
  using the patterns. Learning the benefits and the
  drawbacks of patterns is even more important.
• Given implementation (classes) is a sample only,
  not the only possible, even not the best one.

15
What is even more important

• Patterns are not obligatory. Often, to avoid
  overdesign, we will start from very simple
  solution and (if necessary) refactor it to (or
  towards) of a pattern.
• When we choice the pattern we should consider
  problem and acceptable solution. However, we
  should concern how system might change in the
  future.
• We have to balance between overdesign and
  flexibility.
• Some patterns are considered as overused e.g.
  Singleton (antipattern?)

16
Advantages

• Communication and common language
• All related knowledge in one place
• Forces
• Related patterns
• Solutions
• Way to increase separation of what varying from
  what stay the same
• We can spend (at the beginning) more time on the
  level of design without technical details of
  realization
• We can anticipate some consequences of particular
  solution

17
(No Transcript)
18
(No Transcript)
19
Disadvantages

• Potential overdesign in many cases simple
  solution is enough
• Solution TDD Tests -gt Code -gt Refactoring
• Thinking of patterns that there is a closed,
  inflexible, definitive set and we are not allowed
  to go out from it. (people still discover new
  patterns ) )
• Any real project is fitted to certain pattern. We
  have to adopt patterns to particular application

20
Patterns classification

• Fundamental
• Creational - deal with the creation of
  objectsencapsulate knowledge about which class
  we use and how objects are created.
• Structural - ease the design by identifying a
  simple way to realize relationships between
  entities encapsulate knowledge about interface
  and inner structure.
• Behavioral - that identify common communication
  patterns between objects and realize these
  patterns encapsulate knowledge about algorithms
  and behavior.
• Enterprise

21
Fundamental

• Delegation pattern an object outwardly expresses
  certain behavior but in reality delegates
  responsibility
• Functional design assures that 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

22
Creational

• 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
• 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

23
Creational

• 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

24
Structural

• Adapter pattern 'adapts' one interface for a
  class into one that a client expects
• Aggregate pattern a version of the Composite
  pattern with methods for aggregation of children
• Bridge pattern decouple an abstraction from its
  implementation so that the two can vary
  independently
• Composite pattern a tree structure of objects
  where every object has the same interface
• Decorator pattern add additional functionality
  to a class at runtime where sub classing would
  result in an exponential rise of new classes

25
Structural

• Facade pattern create a simplified interface of
  an existing interface to ease usage for common
  tasks
• 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
• Private class data pattern restrict
  accessor/mutator access

26
Behavioral

• 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 to rapidly solve a specific set
  of problems
• Iterator pattern Iterators are used to access
  the elements of an aggregate object sequentially
  without exposing its underlying representation
• Strategy pattern Algorithms can be selected on
  the fly

27
Behavioral

• 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)
• Null Object pattern Designed to act as a default
  value of an object
• Observer pattern aka Publish/Subscribe or Event
  Listener. Objects register to observe an event
  which may be raised by another object
• State pattern A clean way for an object to
  partially change its type at runtime

28
Behavioral

• 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 Optimize the
  implementation of a visitor that is allocated,
  used only once, and then deleted
• Hierarchical visitor pattern Provide a way to
  visit every node in a hierarchical data structure
  such as a tree.

29
Creation why....?

• Why to not use the constructor ?
• All the constructors have identical names
• Have differ by parameters (number/types)
• Constructors should have not call virtual
  functions
• There may be a lot of variables, so, to avoid
  problems with a long, long list of parameters we
  have to define the structures/classes to
  aggregate them ... for purpose of passing the
  values to the constructor.

30
Creation method?

• Instead
• new Loan(commitment, riskRating, maturity)
• new Loan(commitment, riskRating, maturity,
  expiry)
• new Loan(commitment, outstanding, riskRating,
  maturity, expiry)
• new Loan(capitalStrategy, commitment,
  outstanding, riskRating, maturity, expiry)
• Better
• new Loan(capitalStrategy, commitment,
  outstanding, riskRating, maturity, expiry)
• CreateTermLoan(commitment, riskRating, maturity)
• CreateTermLoan(capitalStrategy, commitment,
  outstanding, riskRating, maturity)
• CreateRevolver(commitment, outstanding, expiry)
• CreateTermLoan(capitalStrategy, commitment,
  expiry, maturity)
• CreateRCTL(commitment, outstanding, riskRating,
  maturity, expiry)
• CreateRCTL(capitalStrategy, outstanding,
  riskRating, maturity, expiry)
• Very general approach similar to Factory Method

31
Factory method

• Do we need to have derived classes figure out
  what to instantiate and decouple client from
  instantiated class?

• Sometimes more general pattern is discussed
  Creation method

32
Abstract factory

• Do we need to create families of objects?
• Consistence of products.
• Introduction new type of product to family
  require refactoring for whole factories class
  hierarchy
• Introduce new class for each new family of
  object.

33
Abstract factory
34
Prototype

• Do we have too many classes to instantiate / or
  is the object creation a cumbersome process?
• Is object type specified at runtime?
• Client configure one prototype and then use it
  for obtaining copies.

35
What about ...?

• Creation of complex object hierarchies eg.
  dictionary tries
• Limitation of instances
• Global access to the particular objects

36
Builder

• Do we need to create object in several steps?
• Decoupling builing algorithm from assemblies.

37
Singleton

• Do we need to limit number of objects of a
  class?
• Centralized access to object.

38
Do you need the ready to code example ...?

• http//www.dofactory.com/Patterns/PatternSingleton
  .aspx_self2
• Do not overuse the singleton conception ...

39
Another issues ...

• Lets assume we have a large object structure
  e.g. tree of objects, dictionaries etc.
• How to provide easy access to the whole structure
  e.g. search etc?
• How to provide the interface to play with
  particular small pieces?

40
Fasade

• Do we want simplify, beautify or OO-fy an
  existing class or subsystem?
• We loss direct access to subsystems.

41
Iterator

• Do we want to separate collection from client
  that's using?
• Access to spreaded information

42
Visitor

• Do we have new tasks that we will need to apply
  to our existing classes?
• Which class from class hierarchy are modified
  most often?
• Visitor fit the best for stable class structure
  and large, varying set of unconnected different
  operation performed on objects.
• Hard to add new class ConcreteElement. It leads
  to modifications all class hierarchy for
  visitors.

43
(No Transcript)
44
Structure ...?

• if we need to control access to the object
• if we need to add/change the functionality but
  the object already exists/we do not create this
  object
• or maybe we need to access the object on remote
  environment
• ... sounds similar ?

45
Proxy

• Do we need to optionally add some new
  functionality to something that already exists?
  Do we need to control how an object is accessed
  (eg. copy on write)?

46
Structure ...?

• Lets assume that we have a good algorithm but
  client would like other interface than our class
  offers.
• Shall we change the implementation we have ? If
  not - what should we to do ?
• We have a class/subclasses but we would like to
  add some new functionality.
• Our class is pretty large we would like to split
  it but how to deal with the change of interface ?
  

47
Adapter

• Do we have the right stuff but wrong interface?
• Two way adaptation classes/objects

48
Decorator

• Do we need multiple additional functions we may
  need to apply, but which and how many we add
  varies, without sub classes?
• Growing number of small objects.

49
Structure ...?

• What about the situation when we have a lot of
  small objects (e.g. Strategy)

50
Flyweight

• Do we have too many part objects?
• Cost of storage ary high due to count of objects?
• Majority of object state can be transfer out side
  object (outer state can be marge in shared
  objects)?
• Identity of objects is not important for system?
• Decresing count of objects.
• Decrising size of objects.
• Calculating or storing inner state?

51
(No Transcript)
52
Structure ...?

• Family of objects that should be handled
  similarly
• Separation of abstraction and implementation

53
Composite
Do we have units and groups and want to treat
them the same way?
54
Bridge

• Do we have one variation using another variation
  in a varying way?
• Sum or product of functionalities of concrete
  implementations?

55
Behavior ...?

• How organize communication between multiple
  objects, components

56
Mediator in real life
57
Mediator
Do we have a lot of coupling in who must talk to
whom?
58
Observer

• Do various entities need to know about events
  that have occurred?
• How to keep dependent object up-to-date?
• More than one observer/observed.
• Explicit specification of changes worth of
  notation.

59
Chain of responsibility
Do we have diffrent objects that can do the job
but we do not wantthe client object know which
is actually going to do it?
60
Command

• Do we need to decouple request from handler?
• Centralized access to functionalities spread over
  whole application (redo/undo)

61
Behavior ...?

• What about internal state of object
• Undo

62
Memento

• Do we need snapshot of the state of object?
• We do not need knowladge about object inner
  structure.
• Costs of creating, settings and carring about
  memento.

63
State

• Do we have a system with lots of states where
  keeping track of code for different states is
  difficult?
• Varing behavior depending on object state (state
  machine).
• Explicit state transition.

64
Interpreter
65
Which aspect of design is easy to change when we
use a pattern?
Type Pattern What could change?
Creational Builder Method of constructing object
Creational Abstract factory Family of objects - products
Creational Factory method Subclass of created object
Creational Prototype Class of created object
Creational Singleton Sole instance of class
66
Type Pattern What could change?
Structural Adapter Object inteface
Structural Decorator Contract without definition subclass
Structural Facade Subsystem inteface
Structural Composite Object structure
Structural Bridge Object implementation
Structural Proxy Method of access to object, object localisation
Structural Flyweight Cost of storage of object
67
Type Pattern What could change?
Behavioral Iterpreter Gramma and interpretation of language
Behavioral Iterator Access way to object
Behavioral Chain of responsibility Object which can attend request
Behavioral Mediator How and which objects affect on the other
Behavioral Template method Steps of algorithm
68
Type Pattern What could change?
Behavioral Observer Count of object dependent from state of another
Behavioral Visitor Operaction which can be appled to object
Behavioral Memento Which private information are stored outside object and when
Behavioral Command Condition and way of realisation of request
69
Type Pattern What could change?
Behavioral State Object state
Behavioral Strategy Algorithm
70
How to choose pattern

• How pattern resolve design problems?
• What is destination of pattern?
• How pattern is connected with other?
• What are the reasons of reshaping project?
• What should be flexible/what could change in
  project?

71
What to read?

• Introduction
• http//codebetter.com/blogs/jeremy.miller/archive/
  2006/04/11/142665.aspx
• http//www.jpboodhoo.com/blog/CommentView,guid,706
  41327-66d4-4200-bd3c-f55d7b3babac.aspx
• Compendium
• GOF Gamma, Helm, Johnson, Vlissides Desgn
  Patterns
• http//www.go4expert.com/forums/showthread.php?t5
  127
• http//www.dofactory.com/Patterns/Patterns.aspx

72
What next ...

• Enterprise Patterns
• Refactoring