Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Design Patterns

15,949 views

Published on

  • Be the first to comment

Design Patterns

  1. 1. Design Patterns Team Effort 27 Aug 2008
  2. 2. Agenda <ul><ul><li>What is a Design Pattern </li></ul></ul><ul><ul><li>Types of Design Patterns </li></ul></ul><ul><ul><li>Behavioural Design Patterns </li></ul></ul><ul><ul><ul><li>GOF Definition </li></ul></ul></ul><ul><ul><ul><li>Basic UML Class Diagram </li></ul></ul></ul><ul><ul><ul><li>Participants </li></ul></ul></ul><ul><ul><ul><li>Intention </li></ul></ul></ul><ul><ul><ul><li>Caveats </li></ul></ul></ul><ul><ul><ul><li>Real-Life Example </li></ul></ul></ul><ul><ul><ul><li>Practical Example </li></ul></ul></ul><ul><ul><ul><li>Questions </li></ul></ul></ul>
  3. 3. Software Design Pattern <ul><li>What is Design Pattern </li></ul><ul><ul><li>Recurring solutions to common problems in software design. </li></ul></ul><ul><li>Types of Patterns </li></ul><ul><ul><li>Creational </li></ul></ul><ul><ul><li>Structural </li></ul></ul><ul><ul><li>Behavioural </li></ul></ul>
  4. 4. Creational Design Patterns <ul><li>Creational Design Patterns </li></ul><ul><ul><ul><li>Abstract </li></ul></ul></ul><ul><ul><ul><li>Factory </li></ul></ul></ul><ul><ul><ul><li>Builder </li></ul></ul></ul><ul><ul><ul><li>Factory Method </li></ul></ul></ul><ul><ul><ul><li>Object Pool </li></ul></ul></ul><ul><ul><ul><li>Prototype </li></ul></ul></ul><ul><ul><ul><li>Singleton </li></ul></ul></ul>
  5. 5. Structural Design Patterns <ul><li>Structural Design Patterns </li></ul><ul><ul><ul><li>Adapter </li></ul></ul></ul><ul><ul><ul><li>Bridge </li></ul></ul></ul><ul><ul><ul><li>Composite </li></ul></ul></ul><ul><ul><ul><li>Decorator </li></ul></ul></ul><ul><ul><ul><li>Facade </li></ul></ul></ul><ul><ul><ul><li>Flyweight </li></ul></ul></ul><ul><ul><ul><li>Private Class Data </li></ul></ul></ul><ul><ul><ul><li>Proxy </li></ul></ul></ul>
  6. 6. Behavioural Design Pattern <ul><li>Behavioural Design Patterns </li></ul><ul><ul><li>Chain of Responsibility Command </li></ul></ul><ul><ul><li>Interpreter Iterator </li></ul></ul><ul><ul><li>Mediator Memento </li></ul></ul><ul><ul><li>Null Object Observer </li></ul></ul><ul><ul><li>State Strategy </li></ul></ul><ul><ul><li>Template Method Visitor </li></ul></ul>
  7. 7. Behavioural Design Patterm <ul><li>Behavioural Design Patterns </li></ul>
  8. 8. Observer Pattern
  9. 9. Observer Pattern – GOF Definition <ul><li>Definition </li></ul><ul><ul><li>Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. </li></ul></ul>
  10. 10. Observer Pattern – Basic UML Diagram <ul><li>Structure </li></ul>
  11. 11. <ul><li>Subject </li></ul><ul><ul><li>Knows its observers. Any number of Observer objects may observe a subject. </li></ul></ul><ul><ul><li>Provides an interface for attaching and detaching Observer objects. </li></ul></ul><ul><li>Observer (View) </li></ul><ul><ul><li>Defines an updating interface for objects that should be notified of changes in a subject. </li></ul></ul>Observer Pattern - Participants
  12. 12. <ul><li>Concrete Observer (GraphicalView/TextView) </li></ul><ul><ul><li>Maintains a reference to a ConcreteSubject </li></ul></ul><ul><ul><li>object. </li></ul></ul><ul><ul><li>Stores state that should stay consistent with </li></ul></ul><ul><ul><li>the subject's. </li></ul></ul><ul><ul><li>Implements the Observer updating interface to </li></ul></ul><ul><ul><li>keep its state consistent with the subject's. </li></ul></ul>Observer Pattern - Participants
  13. 13. Observer Pattern - Intent <ul><li>Intention </li></ul><ul><ul><li>Decoupling </li></ul></ul><ul><ul><li>Maintain consistency between related objects </li></ul></ul>
  14. 14. <ul><li>Caveats </li></ul><ul><ul><li>Dangling reference to deleted subjects. </li></ul></ul><ul><ul><li>Should employ Push or Pull query model according to the need. </li></ul></ul>Observer Pattern - Caveats
  15. 15. <ul><li>Live Example </li></ul><ul><ul><li>Stock Market Ticker </li></ul></ul><ul><li>Example from our Implementation </li></ul><ul><ul><li>XLA framework </li></ul></ul>Observer Pattern - Example
  16. 16. State Pattern
  17. 17. State Pattern – GOF Definition <ul><li>Definition </li></ul><ul><ul><li>Allow an object to alter it's behavior when its internal state changes. The object will appear to change its class. </li></ul></ul>
  18. 18. State Pattern – Basic UML Diagram <ul><li>Structure </li></ul>
  19. 19. State Pattern - Participants <ul><li>Context </li></ul><ul><ul><li>defines the interface of interest to clients </li></ul></ul><ul><ul><li>maintains an instance of a ConcreteState subclass that defines the current state. </li></ul></ul><ul><li>State </li></ul><ul><ul><li>defines an interface for encapsulating the behavior associated with a particular state of the Context. </li></ul></ul><ul><li>Concrete State </li></ul><ul><ul><li>each subclass implements a behavior associated with a state of Context </li></ul></ul>
  20. 20. State Pattern - Intent <ul><li>Intention </li></ul><ul><ul><li>An object-oriented state machine. </li></ul></ul><ul><ul><li>Well defined transition between each state </li></ul></ul><ul><ul><li>Adding a new state/transition is easy by defining new subclasses for each new state introduced. </li></ul></ul>
  21. 21. <ul><li>Caveats </li></ul><ul><ul><li>Having each subclass for the each state increases number of classes and is less compact than a single class. </li></ul></ul>State Pattern - Caveats
  22. 22. <ul><li>Live Example </li></ul><ul><ul><li>Vending machine </li></ul></ul><ul><li>Example from our Implementation </li></ul><ul><ul><li>CLC Command Processor </li></ul></ul>State Pattern - Example
  23. 23. Template Method Pattern
  24. 24. Template Method Pattern – GOF Definition <ul><li>Definition </li></ul><ul><ul><li>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. </li></ul></ul>
  25. 25. Template Method Pattern – Basic UML Diagram <ul><li>Structure </li></ul>
  26. 26. Template Method Pattern - Participants <ul><li>Abstract Class (SortAlgorithm) </li></ul><ul><ul><li>defines abstract primitive operations that concrete subclasses define to implement steps of an algorithm. </li></ul></ul><ul><ul><li>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. </li></ul></ul><ul><li>ConcreteClass (SortAscending/SortDescending) </li></ul><ul><ul><li>implements the primitive operations to carry out subclass-specific steps of the algorithm. </li></ul></ul>
  27. 27. Template Method Pattern - Intent <ul><li>Intention </li></ul><ul><ul><li>Template method pattern should be used to implement the invariant parts of an algorithm once and leave it up to the subclasses to implement the behavior that can vary. </li></ul></ul><ul><ul><li>Code reusability increases. </li></ul></ul>
  28. 28. Template Method Pattern - Caveats <ul><li>Caveats </li></ul><ul><ul><li>It's important for template methods to specify which operations are hooks and which are abstract operations, which will be easy for subclass writers to decide to override the operations. </li></ul></ul>
  29. 29. Template Method Pattern - Example <ul><li>Live Example </li></ul><ul><ul><li>Basic Floor Plan </li></ul></ul>
  30. 30. Memento Pattern
  31. 31. <ul><li>Definition </li></ul><ul><ul><li>Without violating encapsulation, capture and externalize an object’s internal state so that the object can be returned to this state later. </li></ul></ul>Memento Pattern – GOF Definition
  32. 32. Memento Pattern – Basic UML Diagram <ul><li>Structure </li></ul>
  33. 33. Memento Pattern - Participants <ul><li>Originator </li></ul><ul><ul><li>the object that knows how to save itself. </li></ul></ul><ul><li>Caretaker </li></ul><ul><ul><li>the object that knows why and when the Originator needs to save and restore itself. </li></ul></ul><ul><li>Memento </li></ul><ul><ul><li>the lock box that is written and read by the Originator, and shepherded by the Caretaker. </li></ul></ul>
  34. 34. Memento Pattern - Intent <ul><li>Intention </li></ul><ul><ul><li>Promote undo or rollback to full object status . </li></ul></ul>
  35. 35. Memento Pattern - Caveats <ul><li>Cavets </li></ul><ul><li>Memento is used to save sate. Saving and restoring can be time consuming. </li></ul>
  36. 36. Memento Pattern - Example <ul><li>Real-Life Example </li></ul><ul><ul><li>A Word processor providing undo operation on Ctrl+Z </li></ul></ul>
  37. 37. Command Pattern
  38. 38. Command Pattern – GOF Definition <ul><li>Definition </li></ul><ul><ul><li>Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. </li></ul></ul>
  39. 39. Command Pattern – Basic UML Diagram <ul><li>Definition </li></ul>
  40. 40. Command Pattern - Participants <ul><li>Command </li></ul><ul><ul><li>declares an interface for executing an operation </li></ul></ul><ul><li>Concrete Command </li></ul><ul><ul><li>defines a binding between a Receiver object and an action </li></ul></ul><ul><ul><li>implements Execute by invoking the corresponding operation(s) on Receiver </li></ul></ul><ul><li>Client </li></ul><ul><ul><li>creates a ConcreteCommand object and sets its receiver </li></ul></ul>
  41. 41. Command Pattern - Participants <ul><li>Invoker </li></ul><ul><ul><li>asks the command to carry out the request </li></ul></ul><ul><li>Receiver </li></ul><ul><ul><li>knows how to perform the operations associated with carrying out the request. </li></ul></ul>
  42. 42. Command Pattern - Intent <ul><li>Intention </li></ul><ul><ul><li>Decouples the object that invokes the operation from the one that knows how to perform it </li></ul></ul><ul><ul><li>Support undo </li></ul></ul><ul><ul><ul><li>Commands can store additional state so that they can reverse the effect of a previous execute operation </li></ul></ul></ul>
  43. 43. Command Pattern - Caveats <ul><li>Caveats </li></ul><ul><ul><li>The CommandAction class is a generic class that introduces an extra level of indirection and delegates application-specific processing to a pluggable Command object. </li></ul></ul>
  44. 44. Command Pattern - Example <ul><li>Real-Life Example </li></ul><ul><ul><li>The &quot;check&quot; at a diner is an example of a Command pattern. </li></ul></ul>
  45. 45. Chain Of Responsibility Pattern
  46. 46. Chain Of Responsibility – GOF Definition <ul><li>Definition : </li></ul><ul><ul><li>Avoid coupling the sender of the request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. </li></ul></ul>
  47. 47. Chain Of Responsibility – Basic UML Diagram <ul><li>Structure : </li></ul>
  48. 48. Chain Of Responsibility - Participants <ul><li>Handler </li></ul><ul><ul><li>Defines an interface for handling requests </li></ul></ul><ul><ul><li>Implements the successor link (optional) </li></ul></ul><ul><li>Concrete Handler </li></ul><ul><ul><li>Handles requests it is responsible for. </li></ul></ul><ul><ul><li>Can access its successor. </li></ul></ul><ul><ul><li>If the concrete handler can handle the request, it does so, else forwards the request to its successor. </li></ul></ul><ul><li>Client </li></ul><ul><ul><li>Initiates the request to a Concrete handler object on the chain . </li></ul></ul>
  49. 49. Chain Of Responsibility - Intent <ul><li>Intention </li></ul><ul><ul><li>Reduced Coupling </li></ul></ul><ul><ul><ul><li>Instead of objects to maintain references of all candidate receivers, they keep a single reference to their successor. </li></ul></ul></ul><ul><ul><li>Added Flexibility in assigning responsibilities to objects </li></ul></ul><ul><ul><ul><li>Can add or change responsibilities for handling a request by adding to or changing the chain. </li></ul></ul></ul>
  50. 50. Chain Of Responsibility - Caveats <ul><li>Caveats </li></ul><ul><ul><li>Recipient is not guaranteed </li></ul></ul>
  51. 51. Chain Of Responsibility - Example <ul><li>Real-Life Example: Vending Machine </li></ul><ul><li>Rather than having a coin slot for each of the coins, the machine has only one slot for all of them. The dropped coin is routed to the appropriate storage place that is determined by the receiver of the command . </li></ul>
  52. 52. Chain Of Responsibility - Example <ul><li>Practical Implementation </li></ul>
  53. 53. Chain Of Responsibility - Example
  54. 54. Chain Of Responsibility - Example
  55. 55. Interpreter Pattern
  56. 56. Interpreter – GOF Definition <ul><li>Definition </li></ul><ul><ul><li>Given a language, define a representation for its grammar along with an interpreter that uses the interpretation to interpret sentences in the language . </li></ul></ul>
  57. 57. Interpreter – Basic UML Diagram <ul><li>Structure </li></ul>
  58. 58. <ul><li>Abstract Expression (Regular Expression) ‏ </li></ul><ul><ul><li>Declares an abstract interpret operation that is common to all nodes in the abstract syntax tree. </li></ul></ul><ul><li>Terminal Expression (Literal Expression) ‏ </li></ul><ul><ul><li>Implements an interpret operation associated with terminal symbols in a grammar. </li></ul></ul><ul><ul><li>An instance is required for every terminal sentence </li></ul></ul>Interpreter - Participants
  59. 59. Interpreter – Participants (contd..) ‏ <ul><li>Non-Terminal Expression(Alternation, Sequential, Repetition Expression) ‏ </li></ul><ul><ul><li>Implements an interpret operation for non-terminal symbols in the grammar. </li></ul></ul><ul><ul><li>One such class is required for every rule R :: = R1...Rn in the grammar. </li></ul></ul><ul><li>Context </li></ul><ul><ul><li>Contains information global to the interpreter. </li></ul></ul>
  60. 60. Interpreter - Intent <ul><li>Intention </li></ul><ul><ul><li>Easy to change and extend the grammar. </li></ul></ul><ul><ul><li>Easier to add new ways to interpret expressions. </li></ul></ul><ul><ul><li>Complex grammars are hard to maintain </li></ul></ul>
  61. 61. Chain Of Responsibility - Caveats <ul><li>Caveats </li></ul><ul><ul><li>Complex grammars are hard to maintain . </li></ul></ul>
  62. 62. Interpreter - Example <ul><li>Live Example : </li></ul><ul><ul><li>Computer language interpreters. </li></ul></ul><ul><ul><ul><li>Python uses this pattern to generate byte code for a parse tree. </li></ul></ul></ul><ul><ul><li>Text Editors and Web Browsers uses this pattern to lay out documents and check spelling . </li></ul></ul>
  63. 63. Mediator Pattern
  64. 64. Mediator Pattern – GOF Definition <ul><li>Definition </li></ul><ul><ul><li>Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. </li></ul></ul>
  65. 65. Mediator Pattern – Basic UML Diagram <ul><li>Structure </li></ul>
  66. 66. <ul><li>Mediator </li></ul><ul><ul><li>defines an interface for communicating with Colleague objects </li></ul></ul><ul><li>Concrete Mediator </li></ul><ul><ul><li>Implements cooperative behavior by coordinating Colleague objects </li></ul></ul><ul><ul><li>Knows and maintains its colleagues. </li></ul></ul><ul><li>Colleague classes </li></ul><ul><ul><li>Each colleague class knows its Mediator object. </li></ul></ul><ul><ul><li>Each colleague communicates with its mediator whenever it would have otherwise communicated with another colleague. </li></ul></ul>Mediator Pattern - Participants
  67. 67. Mediator Pattern - Intent <ul><li>Intention </li></ul><ul><ul><li>Design an intermediary to decouple many peers. </li></ul></ul><ul><ul><li>A behaviour that's distributed between several classes should be customizable without a lot of subclassing. </li></ul></ul><ul><ul><li>Minimising the interdependency knowledge between the peers. </li></ul></ul><ul><ul><li>Abstraction of interaction is achieved having mediation. </li></ul></ul><ul><ul><li>Mediator replaces many-to-many relationship with one-to-many relationship which is easier to understand, maintain and control. </li></ul></ul>
  68. 68. Mediator Pattern - Caveats <ul><li>Caveats </li></ul><ul><ul><li>This pattern making the Mediator having the centralized control, which over time may become hard to maintain. </li></ul></ul>
  69. 69. Mediator Pattern - Example Real-Life Example: ATC Mediator
  70. 70. Iterator Pattern
  71. 71. Iterator Pattern – GOF Definition <ul><li>Definition </li></ul><ul><ul><li>Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. </li></ul></ul>
  72. 72. Iterator Pattern – Basic UML Diagram <ul><li>Structure </li></ul>
  73. 73. <ul><li>Concrete Iterator </li></ul><ul><ul><li>Implements the iterator interface. </li></ul></ul><ul><ul><li>Keeps track of the current position in the traversal of the aggregate. </li></ul></ul><ul><li>Aggregate </li></ul><ul><ul><li>Defines an interface for creating an iterator object. </li></ul></ul><ul><li>Concrete Aggregate </li></ul><ul><ul><li>Implements the Iterator creation interface to return an instance of the proper concrete Iterator. </li></ul></ul>Iterator Pattern – Participants
  74. 74. Iterator Pattern - Intent <ul><li>Intention </li></ul><ul><ul><li>to access an aggregate object's contents without exposing its internal representation. </li></ul></ul><ul><ul><li>to support multiple traversals of aggregate objects. </li></ul></ul><ul><ul><li>to provide a uniform interface for traversing different aggregate structures (that is, to support polymorphic iteration). </li></ul></ul>
  75. 75. Iterator Pattern - Caveats <ul><li>Caveats </li></ul><ul><ul><li>It's dangerous to modify an aggregate while traversing it, unless it's a robust iterator. </li></ul></ul><ul><ul><li>Inorder for the purpose of traversal, the iterator class will need access to aggregate's private data members. i.e. Aggregate should have iterator as a friend class. </li></ul></ul>
  76. 76. <ul><li>Live Example: </li></ul><ul><ul><li>TV Remote Control – A remote control can traverse throught the channels, without knowing the specific type of television. </li></ul></ul>Iterator Pattern - Example
  77. 77. Strategy Pattern
  78. 78. Strategy Pattern – GOF Definition <ul><li>Definition </li></ul><ul><ul><li>Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from the clients that use it. </li></ul></ul><ul><ul><li>Capture the abstraction in an interface, bury implementation details in derived classes . </li></ul></ul>
  79. 79. Strategy Pattern – Basic UML Diagram <ul><li>Structure </li></ul>
  80. 80. Strategy Pattern – Participants <ul><li>Strategy (Compositor)‏ </li></ul><ul><ul><li>declares an interface common to all supported algorithms. </li></ul></ul><ul><li>Concrete Strategy </li></ul><ul><ul><li>implements the algorithm using the Strategy interface. </li></ul></ul><ul><li>Context </li></ul><ul><ul><li>is configured with a Concrete Strategy object. </li></ul></ul><ul><ul><li>maintains a reference to a Strategy object. </li></ul></ul><ul><ul><li>may define an interface that lets Strategy access its data. </li></ul></ul>
  81. 81. Strategy Pattern - Intent <ul><li>Intention </li></ul><ul><ul><li>many related classes differ only in their behavior. Strategies provide a way to configure a class with one of many behaviors. </li></ul></ul><ul><ul><li>you need different variants of an algorithm. </li></ul></ul><ul><ul><li>an algorithm uses data that clients shouldn't know about. </li></ul></ul><ul><ul><li>Instead of many conditionals, move related conditional branches into their own Strategy class. </li></ul></ul>
  82. 82. Strategy Pattern - Caveats <ul><li>Caveats </li></ul><ul><ul><li>Clients must be aware of different Strategies. </li></ul></ul><ul><ul><li>Strategies increase the number of objects in an application. Sometimes you can reduce this overhead by implementing strategies as stateless objects that contexts can share. </li></ul></ul>
  83. 83. <ul><li>Live Example </li></ul><ul><ul><li>Modes of transportation to an airport is an example of a Strategy. Several options exist such as driving one's own car, taking a taxi, an airport shuttle, a city bus, or a limousine service. </li></ul></ul><ul><ul><li>The traveler must chose the Strategy based on tradeoffs between cost, convenience, and time. </li></ul></ul>Strategy Pattern – Example
  84. 84. <ul><li>Visitor Design Pattern </li></ul>
  85. 85. Visitor Design Pattern <ul><li>Definition </li></ul><ul><ul><li>Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates. </li></ul></ul>
  86. 86. Visitor Pattern – Basic UML Diagram <ul><li>Structure </li></ul>
  87. 87. Visitor Pattern – Participants <ul><li>Visitor‏ </li></ul><ul><ul><li>declares a visit operation for each class of Concrete Element in object structure </li></ul></ul><ul><li>Concrete Visitor </li></ul><ul><ul><li>implements each operation declared by Visitor </li></ul></ul><ul><li>Element </li></ul><ul><ul><li>defines an Accept operation that takes a visitor as an argument. </li></ul></ul>
  88. 88. Visitor Pattern – Participants <ul><li>ObjectStructure </li></ul><ul><ul><li>can enumerate its elements </li></ul></ul><ul><ul><li>may provide a high-level interface to allow the visitor to visit its elements </li></ul></ul><ul><ul><li>may either be a Composite (pattern) or a collection such as a list or a set </li></ul></ul>
  89. 89. Visitor Pattern - Intent <ul><li>Intention </li></ul><ul><ul><li>Need to add new operations </li></ul></ul><ul><ul><li>Need to gather related operations and separate out unrelated ones </li></ul></ul>
  90. 90. Visitor Pattern- Caveats <ul><li>Caveats </li></ul><ul><ul><li>Adding new Concrete Element is hard. </li></ul></ul>
  91. 91. <ul><li>Live Example </li></ul><ul><ul><li>Operation of a Taxi Company. </li></ul></ul>Visitor Pattern – Example
  92. 92. <ul><li>Flyweight Design Pattern </li></ul>
  93. 93. Flyweight Design Pattern <ul><li>Definition </li></ul><ul><ul><li>Use sharing to support large numbers of fine-grained objects efficiently. [GoF, p195] </li></ul></ul>
  94. 94. Flyweight Pattern – Basic UML Diagram <ul><li>Structure </li></ul>
  95. 95. Flyweight Pattern – Participants <ul><li>Client </li></ul><ul><ul><li>Client class which uses flyweight factory </li></ul></ul><ul><li>Flyweight Factory </li></ul><ul><ul><li>Factory which creates concrete flyweights </li></ul></ul><ul><li>Flyweight </li></ul><ul><ul><li>Concrete flyweight and base which has the functionality. </li></ul></ul>
  96. 96. Flyweight Pattern - Intent <ul><li>Intention </li></ul><ul><ul><li>Use sharing to support objects efficiently. </li></ul></ul><ul><ul><li>minimizes memory occupation by sharing as much data as possible with similar objects. </li></ul></ul>
  97. 97. Flyweight Pattern- Caveats <ul><li>Caveats </li></ul><ul><ul><li>Each &quot;flyweight&quot; object is divided into two pieces: the state-dependent (extrinsic) part, and the state-independent (intrinsic) part. Intrinsic state is stored (shared) in the Flyweight object. Extrinsic state is stored or computed by client objects, and passed to the Flyweight when its operations are invoked. </li></ul></ul>
  98. 98. <ul><li>Live Example </li></ul><ul><ul><li>The public switched telephone network is an example of a Flyweight. There are several resources such as dial tone generators, ringing generators, and digit receivers that must be shared between all subscribers. </li></ul></ul>Flyweight Pattern – Example
  99. 99. Chain Of Responsibility - Example
  100. 100. <ul><li>Singleton Design Pattern </li></ul>
  101. 101. Singleton Design Pattern <ul><li>Definition </li></ul><ul><ul><li>Ensure a class has only one instance, and provide a global point of access to it. [GoF, p127] </li></ul></ul>
  102. 102. Singleton Pattern – Basic UML Diagram <ul><li>Structure </li></ul>
  103. 103. Singleton Patter – Participants <ul><li>Client </li></ul><ul><ul><li>Client class accessing singleton </li></ul></ul><ul><li>Singleton </li></ul><ul><ul><li>Singleton object </li></ul></ul>
  104. 104. Singleton Pattern - Intent <ul><li>Intention </li></ul><ul><ul><li>Encapsulated &quot;just-in-time initialization&quot; or &quot;initialization on first use&quot;. </li></ul></ul><ul><ul><li>Provide single point of access to certain data. </li></ul></ul>
  105. 105. Flyweight Pattern- Caveats <ul><li>Caveats </li></ul><ul><ul><li>The &quot;static member function accessor&quot; approach will not support subclassing of the Singleton class </li></ul></ul>

×