1. Unit IV: GoF Design Patterns
Objects Design means Object identification and their relationships, how they interact with each other. (Blue print of the problem, that shows objects and their relationships)

6. Designing Objects With Responsibilities
“Identify requirements, create a domain model and define dynamic behaviour , define messages to meet requirements , add methods to the software classes …”
Too Simple!
How do we assign responsibilities to classes?
What methods belong where?

7. Object Design : Input Use case text System sequence diagram
Defining the behavior
System sequence diagram
Identifying the system operation messages
The operation contract
Stating events to design for, and detailed post-condition to satisfy
Supplementary specification
Defines non-functional goals
Glossary
Data format, data related with UI and database
Domain model
initial attempt of software object in the domain layer of software architecture

8. Responsability Driven Design-RDD
Design of behavior implies assigning responsibilities to software classes.
Responsibilities are assigned to classes of objects during object design.
Responsibility is a contract or obligation of a class
What must a class “know”? [knowing responsibility]
What must a class “do”? [doing responsibility]

9. Doing Responsability What must a class “do”? [doing responsibility]
Take action (create an object, do a calculation)
Initiate action in other objects
Control/coordinate actions in other objects
Doing responsibilities are implemented by means of methods
Methods fulfill responsibilities alone or through collaboration with other objects and methods.
Ex: A Sale is responsible for creating SalesLineItems” (doing)

10. Responsibilities and methods : create
Sale objects are given a responsibility to create Payments.
The responsibility is invoked with a makePayment message

11. knowing responsibility
What must a class “know”? [knowing responsibility]
Knowing responsibilities are related to attributes, associations in the domain model.
Domain model illustrates => inspires the
attributes and associations “knowing” responsibilities.
Ex : a Sale is responsible for knowing its total” (knowing)

12. Responsibilities and attribute

13. RDD and Collaboration
Responsibilities are implemented by methods. Some methods act alone and do a task. Some collaborate with other objects to fulfill their responsibility.
Example:
Sale class has getTotal() method, the getTotal() collaborates with SalesLineItem objects to get the subtotal through getSubtotal() methods

14. Well‐known Pattern Families
GRASP = General Responsibility Assignment Software Patterns
Describe fundamental principles for assigning
responsibilities to classes and for designing
interactions between classes
GoF: Gang of Four Design Patterns : 23 pattrens
We’ll cover with GOF
=>
=>

15. Definitions
A pattern is a recurring solution to a standard problem, in a context.
“A pattern describes a problem which occurs over and over again in our environment, 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 ever doing it the same way twice.”
-by Christopher Alexander,
a professor of architecture…

16. Software pattern What is a software pattern?
A design pattern is a general reusable and proven solution to a commonly occurring problem in software design.
“ a pattern is a named problem/solution pair that can be applied in new contexts, with advice on how to apply it in novel situations”
-by Craig Larman:

17. The “gang of four” (GoF)
Erich Gamma
Richard Helm
Ralph Johnson
John Vlissides

18. The “gang of four” (GoF)
Design Patterns book catalogs 23 different patterns as solutions to different classes of problems, in C++ & Smalltalk
The problems and solutions are broadly applicable, used by many people over many years
Patterns suggest opportunities for reuse in analysis, design and programming
GOF presents each pattern in a structured format

19. Elements of Design Patterns
Design patterns have 4 essential elements:
Pattern name: increases vocabulary of designers
Problem: intent, context, when to apply
Solution: UML-like structure, abstract code
Consequences: results and tradeoffs

20. Three Types of Patterns
Creational patterns (5):
Deal with initializing and configuring classes and objects
Structural patterns (7):
Deal with decoupling interface and implementation of classes and objects
Composition of classes or objects
Behavioral patterns (11):
Deal with dynamic interactions among societies of classes and objects
How they distribute responsibility

21. Creational Patterns Abstract Factory:
Factory for building related objects
Builder:
Factory for building complex objects incrementally
Factory Method:
Method in a derived class creates associates
Prototype:
Factory for cloning new instances from a prototype
Singleton:
Factory for a singular (sole) instance

22. Structural Patterns Adapter:
Translator adapts a server interface for a client
Bridge:
Abstraction for binding one of many implementations
Composite:
Structure for building recursive aggregations
Decorator:
Decorator extends an object transparently
Facade:
Simplifies the interface for a subsystem
Flyweight:
Many fine-grained objects shared efficiently.
Proxy:
One object approximates another

23. Behavioral Patterns Chain of Responsibility:
Request delegated to the responsible service provider
Command:
Request or Action is first-class object, hence re-storable
Iterator:
Aggregate and access elements sequentially
Interpreter:
Language interpreter for a small grammar
Mediator:
Coordinates interactions between its associates
Memento:
Snapshot captures and restores object states privately

24. Behavioral Patterns (cont.)
Observer:
Dependents update automatically when subject changes
State:
Object whose behavior depends on its state
Strategy:
Abstraction for selecting one of many algorithms
Template Method:
Algorithm with some steps supplied by a derived class
Visitor:
Operations applied to elements of a heterogeneous object structure

25. GoF Design Patterns
If you aren't an experienced object-oriented designer, then start with the simplest and most common patterns:
Adapter (Structural pattern)
Factory(Creational pattern)
Singleton(Creational pattern)
Strategy(Behavioral pattern)
Composite(Structural pattern)
Façade(Structural pattern)
Observer (Behavioral pattern)
Command (Behavioral pattern)

26. Describing Design Patterns
Pattern Name and Classification
Intent
A short statement that answers the following questions:
What does the design pattern do?
What is its rationale and intent?
What particular design issue or problem does it address?
Also Known As
Other well-known names for the pattern, if any.

27. Motivation Applicability
A scenario that illustrates a design problem and how the class and object structures in the pattern solve the problem. The scenario will help you understand the more abstract description of the pattern that follows.
Applicability
What are the situations in which the design pattern can be applied?
What are examples of poor designs that the pattern can address? How can you recognize these situations

28. Structure Participants
A graphical representation of the classes in the pattern using a notation based on the Object Modeling Technique (OMT) [RBP+91]. We also use interaction diagrams [JCJO92, Boo94] to illustrate sequences of requests and collaborations between objects.
Participants
The classes and/or objects participating in the design pattern and their responsibilities.

29. Consequences Implementation
How does the pattern support its objectives? What are the trade-offs and results of using the pattern? What aspect of system structure does it let you vary independently?
Implementation
What pitfalls, hints, or techniques should you be aware of when implementing the pattern? Are there language-specific issues?

30. Sample Code Known Uses Related Patterns
Code fragments that illustrate how you might implement the pattern in C++ or Smalltalk.
Known Uses
Examples of the pattern found in real systems. We include at least two examples from different domains.
Related Patterns
What design patterns are closely related to this one? What are the important differences? With which other patterns should this one be used?

31. Adapter Pattern (26.1)
Problem: How to resolve incompatible interfaces, or how to provide a stable interface to similar components with different interfaces.
Solution: Convert the original interface of a component into another interface, through an intermediate adapter object.
Note: the Adapter pattern is an application of Polymorphism

32. Adapter Pattern (26.1)
Example: POS needs to adapt several kinds of external third-party services: tax calculators, credit authorization services, inventory systems, accounting systems. Each has a different API which can’t be changed.

33. Fig. 26.1

34. Fig. 26.2

35. Adapter Pattern (26.1)
Note: Adapter pattern follows GRASP principles: Polymorphism, Protected Variation, Indirection
See Fig for conceptual connection among GRASP principles and Adapter pattern

36. Fig. 26.3

37. Factory Pattern (26.4)
Problem: Who should be responsible for creating objects when there are special considerations such as complex creation logic, a desire to separate creation responsibilities for better cohesion, etc.?
Solution: Create a Pure Fabrication object called a Factory that handles the creation.

38. Factory Pattern (26.4)
A variation of GoF Abstract Factory pattern

39. Fig. 26.5

40. Factory Pattern (26.4)
Note: In Fig the implementation of ServicesFactory illustrates data-driven design – a form of Protected Variation

41. Factory Pattern (26.4)
Idea: Define an object whose purpose is to create objects
Benefits:
Separate the responsibility of complex creation into cohesive helper objects
Can provide object caching (e.g. having only one random number generator)

42. Singleton Pattern (26.5)
Problem: Exactly one instance of a class is allowed. Objects need a global and single point of access.
Solution: Define a static method of the class that returns the singleton: getInstance()

43. Singleton Pattern (26.5)
Consider the factory and how it is accessed – who creates the factory?
Only want one instance of the factory
Methods may need to be called from various places => how to make single instance of the factory globally visible
Could pass the ServicesFactory instance around as a parameter whenever visibility is required or initialize all objects that need it with a permanent reference to it
Singleton – supports global visibility or a single access point to a single instance

44. Fig. 26.6

45. Singleton Pattern (26.5)
Note: concurrency control in ServicesFactory – making getInstance() synchronized
Fig shows how Adapter, Factory, Singleton patterns are used in design

46. Fig. 26.8

47. Singleton pattern (creational)
Ensure that a class has only one instance and provide a global point of access to it
Why not use a global variable?
class Singleton
{ public:
static Singleton* getInstance();
protected: //Why are the following protected?
Singleton();
Singleton(const Singleton&);
Singleton& operator= (const Singleton&);
private: static Singleton* instance; };
Singleton *p2 = p1->getInstance();

48. Strategy Pattern (26.7)
Problem: How to design for varying but related algorithms or policies? How to design for the ability to change these algorithms or policies?
Solution: Define each algorithm/strategy in a separate class with a common interface

49. Strategy Pattern (26.7)
Example: How to provide more complex pricing logic, e.g. store-wide discount, senior citizen discount, employee discount, etc.
A pricing strategy for a sale can vary, how do we design for these varying pricing algorithms?

50. Fig. 26.9

51. Strategy Pattern (26.7)
Example: Create multiple SalePricingStrategy classes each with a polymorphic getTotal() operation
Note: each getTotal() operation takes a Sale object as a parameter so that the strategy object can find the pre-discount price from the Sale
The implementation of each getTotal() will differ
A strategy object is attached to a context object – the object to which it applies the algorithm, e.g. Sale

52. Fig

53. Strategy Pattern (26.7) Example:
When a getTotal() message is sent to a Sale it delegates work to its strategy object
It is common for the context object to pass a reference to itself to the strategy object so that the strategy object has parameter visibility to the context object

54. Fig

55. Strategy Pattern (26.7) Example: Who should create the strategy?
Apply the Factory pattern: a PricingStrategyFactory
The PricingStrategyFactory is a singleton and accessed via the Singleton pattern

56. Fig

57. Fig

58. Strategy Pattern (26.7) Note:
Strategy is based on Polymorphism and provides Protected Variation with respect to changing algorithms
Strategies are often/usually created by a Factory

59. Composite Pattern (26.8)
Problem: How to treat a group or composition structure of objects the same way (polymorphically) as a non-composite (atomic) object?
Solution: Define classes for composite and atomic objects so that they implement the same interface.

60. Composite Pattern (26.8)
Design problem: How to handle multiple conflicting pricing policies?
Example:
20% senior discount
Preferred customer discount of 15% off sales over $400
On Monday, there is a $50 off purchases over $500
Buy one case of Darjeeling tea, get 15% discount off everything

61. Composite Pattern (26.8)
Example (cont.): Pricing strategies determined by
Time period (Monday)
Customer type (senior)
Line item product (Darjeeling tea)
In addition to pre-discount price
May have multiple co-existing strategies
Customer type and type of product may need to be known at time strategy is created (i.e. known by StrategyFactory)

62. Composite Pattern (26.8)
Example (cont.): Now how do we design so that the Sale object does not know if it is dealing with one or many pricing strategies and also offer a design for the conflict resolution
Composite pattern!

63. Composite Pattern (26.8) Key feature:
The composite object contains a list of inner objects and both the composite object and the inner objects implement the same interface

64. Fig

65. Composite Pattern (26.8)
The Sale object treats a Composite Strategy that contains other strategies as any object that implements ISalePricingStrategy (i.e., calls its getTotal(s) operation)
See code pp
Notation for abstract classes and abstract methods – see Fig

66. Fig

67. Façade Pattern (26.9)
Problem: A common unified interface to a disparate set of implementations or interfaces – such as within a subsystem – is required. There may be undesirable coupling to many things in the subsystem, or the implementation of the subsystem may change. What to do?
Solution: Define a single point of contact to the subsystem – a façade that wraps the subsystem. This façade object presents a single unified interface and is responsible for collaborating with the subsystem components.

68. Façade Pattern (26.9)
A façade object serves as a “front-end” object that is the single point of entry for the services of a subsystem
Façade provides Protected Variation from changes in the implementation of the subsystem

69. Façade Pattern (26.9)
Example: A “rule engine” subsystem – responsible for evaluating a set of rules against an operation and indicating if any rules invalidate the operation
Example of a rule: If the sale is paid by a gift certificate, invalidate all payment types of change due back to the customer except for another gift certificate.
Also known as pluggable business rules

70. Façade Pattern (26.9)
Example (cont): Define a façade object to this subsystem: POSRuleEngineFacade
Calls to this façade placed near the start of methods that are points for pluggable rules, see code p. 462
The hidden subsystem could contain any number of rules

71. Fig

72. Façade Pattern (26.9) Notes: Façade is usually accessed via Singleton
Similar to Adapter but Adapter applies to varying interfaces not hiding implementation of subsystem

73. Observer pattern Intent: Used in Model-View-Controller framework
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically
Used in Model-View-Controller framework
Model is problem domain
View is windowing system
Controller is mouse/keyboard control
How can Observer pattern be used in other applications?
JDK’s Abstract Window Toolkit (listeners)
Java’s Thread monitors, notify(), etc.

74. Structure of Observer Pattern

75. Observer Pattern (26.10) Also known as Publish-Subscribe Pattern
Problem: Different kinds of subscriber objects are interested in state changes or events of a publisher object and want to react in their own unique way when the publisher generates an event. The publisher wants to maintain low coupling to the subscribers.
Solution: Define a subscriber or listener interface. Subscribers implement the interface. The publisher can dynamically register subscribers who are interested in an event and notify them when an event occurs.

76. Observer Pattern (26.10)
Example: Want a GUI window to refresh (update) its display of sale total when the total changes
See Fig

77. Fig

78. Observer Pattern (26.10) Example (cont):
Simple solution – when Sale changes its total the object sends a message to the window telling it to refresh its display
Problem – high coupling between domain objects and UI objects

79. Observer Pattern (26.10) Example (cont):
Want to be able to easily replace UI objects or even add other UI objects that can be notified of this event
That is, want model-view separation
Model objects shouldn’t know about view objects => Protected Variations with respect to a changing user interface

80. Fig

81. Observer Pattern (26.10) Steps (p. 465)
Define an interface PropertyListener with operation onPropertyEvent
Define window (SaleFrame1) to implement the interface
When SaleFrame1 is initialized pass it the Sale instance from which it is displaying the total
SaleFrame1 registers to the Sale instance for notification of “property events” via the addPropertyListener message
Note that the Sale does not know about SaleFrame1 objects; it only knows about objects that implement the PropertyListener interface. (This lowers the coupling of the Sale to the window – the coupling is only to an interface, not to a GUI class.)
The Sale instance is the publisher of “property events”. When the total changes, it iterates across all subscribing PropertyListeners, notifying each

82. Observer Pattern (26.10) Notes:
The SaleFrame1 object is the observer/subscriber/listener
Sale is the publisher of property events
Sale adds SaleFrame1 object to its list of PropertyListener subscribers – Fig

83. Fig

84. Observer Pattern (26.10) Notes:
When the Sale total changes it iterates over all registered subscribers and sends the onPropertyEvent message to each – Figs , 26.25

85. Fig

86. Fig

87. Who is the observer, listener, subscriber, and publisher?
Fig
Who is the observer, listener, subscriber, and publisher?

88. Observer Pattern (26.10) Notes:
Sale is coupled to view object but only loosely since it only knows subscribers as implementing the PropertyListener interface
In Java this was called Delegation Event Model
Observer pattern is basis for GUI widget event handling in both Java (AWT & Swing) and .NET
Widgets are publishers of events, other objects can register as listeners

89. Observer Pattern (26.10) Example of AlarmClock:
AlarmClock is publisher of alarm events
Different types of objects can register as listeners and react to same alarm event in their own ways

90. Fig

91. Command pattern
Synopsis or Intent: Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations
Context: You want to model the time evolution of a program:
What needs to be done, e.g. queued requests, alarms, conditions for action
What is being done, e.g. which parts of a composite or distributed action have been completed
What has been done, e.g. a log of undoable operations
What are some applications that need to support undo?
Editor, calculator, database with transactions
Perform an execute at one time, undo at a different time
Solution: represent units of work as Command objects
Interface of a Command object can be a simple execute() method
Extra methods can support undo and redo
Commands can be persistent and globally accessible, just like normal objects

92. Command pattern, continued
Structure:
Participants (the classes and/or objects participating in this pattern): Command  (Command) declares an interface for executing an operation
ConcreteCommand  defines a binding between a Receiver object and an action
implements Execute by invoking the corresponding operation(s) on Receiver
Invoker asks the command to carry out the request
Receiver knows how to perform operations associated with carrying out the request
Client creates a ConcreteCommand object and sets its receiver

93. Command pattern, continued
Consequences:
You can undo/redo any Command
Each Command stores what it needs to restore state
You can store Commands in a stack or queue
Command processor pattern maintains a history
It is easy to add new Commands, because you do not have to change existing classes
Command is an abstract class, from which you derive new classes
execute(), undo() and redo() are polymorphic functions

94. Benefits of Design Patterns
Design patterns enable large-scale reuse of software architectures and also help document systems
Patterns explicitly capture expert knowledge and design tradeoffs and make it more widely available
Patterns help improve developer communication
Pattern names form a common vocabulary