1. Design Patterns
Satya Puvvada
Satya Puvvada

2. Objectives
Gain an understanding of using design patterns to improve design and implementation
Learn to develop robust, efficient and reusable C++ programs using design patterns
Satya Puvvada

3. Contents – Day 1 Introduction to design patterns
Introduction to UML notation
Patterns
Singleton
Factory method
Abstract Factory
Observer
Strategy
Adapter
Visitor
Satya Puvvada

4. Contents – Day 2 Patterns Builder Bridge Facade Proxy Composite
Chain of responsibility
Command
Satya Puvvada

5. Contents – Day 3 Patterns Case Study References and conclusions
Flyweight
Memento
State
Decorator
Prototype
Mediator
Case Study
References and conclusions
Satya Puvvada

6. Satya Puvvada

7. FlyWeight
Use sharing to support large numbers of fine-grained objects efficiently.
Satya Puvvada

8. FlyWeight
If each character is an object in a text editor, number of objects > for moderately sized documents
Share objects to reduce the number of objects but gives the same flexibility
Intrinsic v/s extrinsic state (value of the character v/s location to be drawn)
Extrinsic state is always supplied by the client
Satya Puvvada

9. FlyWeight
Satya Puvvada

10. Flyweight: Structure
Satya Puvvada

11. Flyweight example
Satya Puvvada

12. Flyweight: Instances
Satya Puvvada

13. Flyweight - Consequences
May introduce runtime costs due to transferring of book keeping of shared objects, computing intrinsic state etc – but this offset by the savings in space and flexiblility offered
The more flyweights shared – more the space savings
Satya Puvvada

14. Flyweight - Consequences
Source code
Satya Puvvada

15. Memento
Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.
Satya Puvvada

16. Memento Structure…
Satya Puvvada

17. Memento
Source code
Satya Puvvada

18. State
Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
Satya Puvvada

19. Example
Satya Puvvada

20. Structure
Satya Puvvada

21. Consequences
It localizes state-specific behavior and partitions behavior for different states
It makes state transitions explicit
State objects can be shared
Satya Puvvada

22. Decorator - Intent
Attach additional responsibility to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
Satya Puvvada

23. Synopsis Provides a dynamic and lightweight substitute for subclassing
Each object is only decorated with the functionality it needs
Takes full advantage of the class hierarchy and inheritance
Satya Puvvada

24. Context Many possible uses
X windows uses Decorators to apply decorations to windows, hence the name
Generally used when the programmer wants many instances of the same parent class with many different behaviors, but without creating many subclasses.
Satya Puvvada

25. Forces
Suppose you have a user interface toolkit and you wish to make a border or scrolling feature available to clients without defining new subclasses of all existing classes. The client "attaches" the border or scrolling responsibility to only those objects requiring these capabilities.
Widget* aWidget = new BorderDecorator(
new HorScrollDecorator(
new VerScrollDecorator(
new TextWidget( 80, 24 ))));
aWidget->draw();
Satya Puvvada

26. Forces Allows transparent addition of functionality.
Decorators are decoupled from base class and each other.
Decorators can be added or removed dynamically and easily.
Satya Puvvada

27. Solution
Enclose the base class in a decorator class that maintains the same interface
Totally transparent to program using the Decorators and to other decorators
Satya Puvvada

28. Consequences Good Things Bad things
Allows the use of multiple decorators, including the same one multiple times
Totally decoupled. Each decorator is only aware of the thing it is decorating, and the base class is not aware that it has been decorated.
Bad things
Can be difficult to remove specific decorators dynamically
Decorator has the same interface as base class, but is not the same object, which can lead to problems if, for example, the address of the base class is needed
Satya Puvvada

29. Implementation
If the object needs to call itself or pass itself, it may need to pass its decorators as well. If this is the case, it must be made aware of them.
Changing the middle decorator of a pile can be like removing the middle layer of noodles from lasagna. It’s possible, but easier said than done and quite messy.
Satya Puvvada

30. Related patterns Adapter changes interface Proxy duplicates interface
Decorator enhances interface
Satya Puvvada

31. PROTOTYPE (Object Creational)
Intent:
Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
Motivation:
Framework implements Graphic class for graphical components and GraphicTool class for tools manipulating/creating those components
Actual graphical components are application-specific
How to parameterize instances of GraphicTool class with type of objects to create?
Solution: create new objects in GraphicTool by cloning a prototype object instance
Satya Puvvada

32. PROTOTYPE Motivation Satya Puvvada Tool Graphic Manipulate()
Draw(Position)
Clone()
prototype
Staff
MusicalNote
Rotate Tool
Graphic Tool
Draw(Position)
Clone()
Manipulate()
Manipulate()
WholeNote
HalfNote
p = prototype ->Clone()
while(user drags mouse){
p ->Draw(new position) }
Insert p into drawing
Draw(Position)
Clone()
Draw(Position)
Clone()
Return copy of self
Return copy of self
Return copy of self
Satya Puvvada

33. Applicability
Use the Prototype pattern when a system should be independent of how its products are created, composed, and represented;
when the classes to instantiate are specified at run-time, for example, by dynamic loading; or
to avoid building a class hierarchy of factories that parallels the class hierarchy of products; or
when instances of a class can have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state.
Satya Puvvada

34. PROTOTYPE Structure Satya Puvvada prototype client Prototype
Operation()
Clone()
p = prototype ->Clone()
ConcretePrototype1
ConcretePrototype2
Clone()
Clone()
return copy of self
return copy of self
Satya Puvvada

35. Participants and Collaborations
Prototype (Graphic)
Declares an interface for cloning itself
ConcretePrototype (Staff, WholeNote, HalfNote)
Implements an interface for cloning itself
Client (GraphicTool)
Creates a new object by asking a prototype to clone itself
Collaborations:
A client asks a prototype to clone Itself.
Satya Puvvada

36. Mediator - Synopsis
The mediator design pattern creates a class to mediate between a group of colleague objects
The mediator handles all interaction between colleague objects
All related colleague objects have the same mediator
Satya Puvvada

37. Mediator Mediator Mediator Colleague ConcreteMediator
ConcreteColleague1
ConcreteColleague2
Satya Puvvada

38. Context
Allows organization of relationships and interactions between objects
Used where complex protocols must be managed
Used when centralized access points are needed
Keeps objects in a group from referring to each other explicitly
Satya Puvvada

39. Context Example: Chat room Has multiple users User joins chat room
Users send messages to other users
Users receive messages from other users
Satya Puvvada

40. Forces It’s a complex task to manage communication between users
If user clients communicated directly, each client would need to understand every other type of client
Each client needs to know about every other client to send their messages
Inherent coupling of objects that need to communicate
Satya Puvvada

41. Solution
Mediator
All users (colleagues) communicate with a common mediator
User logs in, mediator is notified
Message I/O
User sends messages to mediator
Mediator sends message to all user clients (colleagues)
Satya Puvvada

42. Consequences Pros Cons Less chance of miscommunication
No need to “poll” for new colleagues
Promotes reusability
Cons
Waste of effort for few colleagues
Mediator can become bloated
Satya Puvvada

43. Consequences Limits sub-classing Decouples colleagues
Simplifies object protocols
Makes object cooperation abstract
Centralizes control
Satya Puvvada

44. Related Patterns Observer Adapter Façade
Mediator class can be implemented using an observer
Adapter
If mediator was allowed to change the data it’s mediating, it would be an adapter
Façade
Similar
Façade only has one-way communication to its colleagues
Satya Puvvada

45. Case Study
Satya Puvvada

46. Designing a file system
Satya Puvvada

47. Conclusions
Satya Puvvada

48. Motivation for Design Patterns
Most software systems contain certain common aspects that are frequently reinvented for each system
Solutions to these common problems may vary in quality from system to system
Design patterns seeks to communicate these classic solutions in an easy to understand manner
Satya Puvvada

49. What are Design Patterns?
Design Patterns communicate solutions to common programming problems
The seminal book on design patterns, Design Patterns, Elements of Reusable Object-Oriented Software by Gamma et al, identifies three categories of design patterns
Creational
Structural
Behavioral
Satya Puvvada

50. Creational Patterns Abstract factory Builder Factory method
Facilitates the creation of related objects without concrete class reference
Builder
If a class supports a number of different data representations, the builder encapsulates the details of the necessary conversions
Factory method
Defers determination of specific class to create to a subclass
Satya Puvvada

51. More Creational Patterns
Prototype
Embodies information comprising prototypical instances
Singleton
Ensures that the class has at most one instance and that other classes have global access to it
Satya Puvvada

52. Structural Patterns Adapter Bridge Composite Decorator
Translates between interacting objects for which the method signatures are incompatible
Bridge
Creates a more flexible mechanism for multiple implementations of an abstract class than inheritance
Composite
Facilitates a generic hierarchical grouping of objects where the class and number of objects may change
Decorator
Allows dynamic addition of new behavior to objects by acting as an outer wrapper containing the added features
Satya Puvvada

53. More Structural Patterns
Facade
Provides a front end for a series of classes so that users of these classes only need to know of and use the standard set of methods implemented by the facade
Flyweight
Describes a strategy for using an otherwise prohibitive number of very small-scale objects with minimal overhead
Proxy
A means by which the instantiation of certain classes may be delayed until the proxied object is needed
Satya Puvvada

54. Behavioral Patterns Chain of responsibility Command Interpreter
A strategy that sets up a series of objects that may respond to a message depending on the context of the request
Command
Allows methods to be encapsulated in objects and invoked by a standard means as determined by the interface of the common class
Interpreter
If a set of problems are conducive to being represented as a simple grammar, a class may be defined for each rule
Satya Puvvada

55. More Behavioral Patterns
Iterator
Separates the class elements necessary for access and traversal from the aggregating class and encapsulates them in the iterator
Mediator
Helps to avoid highly coupled class definitions by moving explicit object references to an intermediary object
Memento
A means to store the otherwise encapsulated internal state of an object for the purpose of creating a check-point or undoing transactions
Satya Puvvada

56. More Behavioral Patterns
Observer
Allows multiple dependent instances of a class to be notified of relevant changes to the observed class
State
A class hierarchy is defined around a set of states for an object, allowing the behavior of an object to vary depending on a state by substituting the state-specific subclass in its composition
Strategy
Selects a set of related algorithms and encapsulates them in such a way that they may be interchangeable for solving certain problems
Satya Puvvada

57. More Behavioral Patterns
Template method
Structures a method in such a way that elements of the algorithm are deferred to subclasses
Visitor
Allows the introduction of new operations on the objects that comprise the visited object
Satya Puvvada

58. Conclusions Individual Patterns are deceptively simple.
Composition of different patterns can be very complex.
Teams may suffer from pattern overload.
Patterns are validated by experience and discussion rather than by automated testing.
Integrating patterns into a software development process is a human­intensive activity.
Satya Puvvada

59. References Books Design Patterns (Erich Gamma et al.)
Design Patterns for OO Software Development (Wolfgang Pree)
Object Models: Strategies, Patterns and Applications (Peter Coad et al.)
Pattern Languages of Program Design (James O. Coplien et al. eds.)
Pattern Languages of Program Design 2 (John M. Vlissides et al. eds.)
Pattern Languages of Program Design 3 (Robert C. Martin, Dirk Riehle, Frank Buschmann eds.)
Pattern Languages of Program Design 4 (Brian Foote, Neil Harrison, Hans Rohnert eds.)
Patterns of Software (Richard P. Gabriel)
Pattern-Oriented Software Architecture (F. Buschmann et al.)
Satya Puvvada

60. References Patterns on the web
Patterns Home Page:
Wiki Wiki Web
Portland Pattern Repository (Ward Cunningham)
AntiPatterns (KeithDerrick)
Best Pattern Threads
History of Patterns
PeopleIndex (Ward Cunningham)
ProjectIndex (Ward Cunningham)
Satya Puvvada

61. Conclusions Introduction to Design patterns UML Notation
20 patterns from the various categories discussed
Case study
All the best !!!!!
Satya Puvvada