Design Pattern lecture 4


Published on

Behavioral Design Patterns
Chain of Responsibility
Template Method

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • A group of classes each have processes to run in turn, but there is no way to directly determine in which class order each should runits process
  • Allows a request to an object to exist as an objectUsed for doing and undoing and storing a request queue for an objectExample: A document object needs a way to add and store undo and redo actions
  • Allows group of objects to communicate in a disassociated manner and encapsulates this communication while keeping the objects loosely coupled.
  • Capture an object’s internal state without violating encapsulation of the object, and preserve that state for some purpose.
  • Originator class whose internal state to captureMemento  class in which we store the originator’s stateCaretaker  stores the memento until needed to restore the state or originator
  • Design Pattern lecture 4

    1. 1. Design Pattern By Julie IskanderMSc. Communication and Electronics
    2. 2. Outlines Lecture 4• Behavioral Design Patterns • Chain of Responsibility • Command • Mediator • Memento • Observer • State • Strategy • Template Method • Interpreter • Visitor • Iterator (Reading Assignment)
    3. 3. Behavioral Patterns
    4. 4. Chain of responsibility DP• What • A replication of the business or functional process of delegating responsibility within a hierarchy.• Where • A requirement to manage tasks by coordinating objects and have them cooperate within a hierarchical structure.• Why • Avoid coupling sender of request to receiver• How • An abstract class that represents a participant or link is sub- classed into a set of links, and then the sub-classed links implement the functionality that represents their responsibility and can trigger the passing on of a requirement. The client determines the hierarchy among the links and initiates passing the requirement to the chain.
    5. 5. Chain of responsibility dp
    6. 6. Chain of responsibility dp
    7. 7. Chain of responsibility dp
    8. 8. Chain of responsibility
    9. 9. Chain of responsibility
    10. 10. Command DP(object - Behavioral DP)
    11. 11. Command DP (object - Behavioral DP)• What • Encapsulate a request as an object, and support undoable operations.• Where • To issue requests to objects without knowing anything about the operation being requested or the receiver of the request.• Why • specify, queue, and execute requests at different times. support undo. support logging changes
    12. 12. Command DP(object - Behavioral DP)
    13. 13. Command DP(object - Behavioral DP)
    14. 14. Command DP(object - Behavioral DP)
    15. 15. Command DP(object - Behavioral DP)
    16. 16. Command DP (object - Behavioral DP)• Supporting undo and redo: • Must provide a reverse method (Unexecute/Undo). • Might need to store additional state like the Receiver object, the arguments to the operation performed on the receiver, and any original values in the receiver that can change as a result of handling the request. • For one level of undo, store only the last executed command. • For multi-level undo, store a history list of executed commands.
    17. 17. Mediator DP (object - Behavioral DP)• What • 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.• Where • when many objects interconnect, to lessen the coupling• Why • To lessen the coupling between objects• How • Encapsulating collective behavior in a separate mediator object. A mediator is responsible for controlling and coordinating the interactions of a group of objects. The objects only know the mediator, thereby reducing the number of interconnections.
    18. 18. Mediator DP(object - Behavioral DP)
    19. 19. Mediator DP(object - Behavioral DP)
    20. 20. Mediator DP(object - Behavioral DP)
    21. 21. Mediator DP(object - Behavioral DP)
    22. 22. Mediator DP(object - Behavioral DP)
    23. 23. Mediator DP(object - Behavioral DP)
    24. 24. Mediator DP (object - Behavioral DP)• Façade make requests to the subsystem, while mediator enables cooperative behaviour between colleagues objects
    25. 25. MeMento DP (object - Behavioral DP)• What • capture and externalize an objects internal state so that the object can be restored to this state later.• Where • To store a snapshot of internal state of an object, to implement checkpoints• Why • To implement checkpoints, save state, undo mechanisms• How
    26. 26. MeMento DP(object - Behavioral DP)
    27. 27. MeMento DP(object - Behavioral DP)
    28. 28. MeMento DP (object - Behavioral DP)• Memento objects are passive• Memento can be used to maintain state for undoable operations for Command DP• Used in Games to store check points
    29. 29. Observer DP(object - Behavioral DP)
    30. 30. Observer DP (object - Behavioral DP)• What • An Observer pattern is a design based on a one-to-many relationship, where one is a publisher that publishes an event against which many subscribers register an interest.• Where • A requirement to initiate and manage communications among a society of objects.• Why • To programmatically establish and manage a set of relationships among objects at run time.• How • Create a subject object (publisher) and any number of observer objects (subscribers), and then wire an event handler in the observer objects to an event in the subject object. In .NET, we use a delegate event-handling model to wire the observer objects to the publishers event—delegates simplify the architecture articulated by GoF.
    31. 31. Observer DP(object - Behavioral DP)
    32. 32. Observer DP(object - Behavioral DP)
    33. 33. Observer DP(object - Behavioral DP)
    34. 34. State DP (object - Behavioral DP)• What • Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.• Where • An objects behavior depends on its state, and it must change its behavior at run-time depending on that state.• Why • This lets you treat the objects state as an object in its own right that can vary independently from other objects.
    35. 35. State DP(object - Behavioral DP)
    36. 36. State DP(object - Behavioral DP)
    37. 37. Strategy DP (object-behavioural DP)• What • A design that presents a family of algorithms or business rules encapsulated in classes that can be swapped.• Where • A requirement for the contextual implementation of different algorithms or business rules without the use of conditional code.• Why • A design that separates the choice of algorithm or business rule from its implementation and delegates the contextual choice of algorithm or business rule to client code.• How • Design an abstract strategy class that includes an abstract method from which an algorithm may be called. Prepare a context class to contain an abstract strategy class and then code the client to choose the strategy and inform the context
    38. 38. Strategy DP(object-behavioural DP)
    39. 39. Template Method DP (Class - Behavioral DP)• What • Need subclasses to house different implementations of an algorithm and defer part of the implementation to the subclass.• Where • A requirement for a common structure to house an algorithm, while vary the implementation of the algorithm.• Why • A default implementation that has the flexibility for a subclass to vary the underlying algorithm within the implementation.• How • An abstract class exposes a Template Method that wraps a set
    40. 40. Template Method DP(Class - Behavioral DP)
    41. 41. Template Method DP(Class - Behavioral DP)
    42. 42. Template Method DP (Class - Behavioral DP)• Factory Methods are often called by template methods. (DoCreateDocument called by OpenDocument).• Template methods use inheritance to vary part of an algorithm. Strategies use delegation to vary the entire algorithm.
    43. 43. Report #3:Interpreter DPVisitor DPN.B. Hand Written 
    44. 44. References[1] Design Patterns, Christopher G. Lasater, Wordware Publishing, Inc.[2], How I explained OOD to my wife, Al-Farooque Shubho[3],PrinciplesOfOod[4]http://www.CodeProject.comHow I explained Design Patterns to my wife:Part 1,By Al-FarooqueShubho[5],Al-FarooqueShubho[6]C# 3.0 Design Patterns, Judith Bishop[7]Head First Design Pattern, Eric Freeman, Elisabeth Freeman, KathySierra, Bert Bates[8] Pro .NET 2.0 Code and Design Standards in C#, Mark Horner
    45. 45. The End Thank you and Good Luck