Behavioral Design Patterns

Behavioral Design Patterns
Foundations of Software Engineering, Ben Gurion University, Fall 2015

Observer, Mediator, State, Strategy, Iterator, Visitor

Transcript

1. Behavioral Design Patterns Lidan Hifi Sagi Avasker Amit Bedarshi Foundations of software engineering, Fall 2015
2. Agenda • What is Behavioral Design Pattern? • Observer • Mediator • State • Strategy • Iterator • Visitor
3. Behavioral Patterns • Defines the communication between objects. • Dynamic behavior (changeable in runtime) using polymorphism. • Objects are able to talk each other, and still loosely coupled!
4. Behavioral Patterns • Defines the communication between objects. • Dynamic behavior (changeable in runtime) using polymorphism. • Objects are able to talk each other, and still loosely coupled!
5. Last Summer
7. Motivation Define a one-to-many dependency between objects, so that when one object changes its state, all its dependents are notified and 
 updated automatically.
8. Solution #1: Busy-wait
9. Solution #1: Busy-wait
10. Solution #2: Notification through composition
11. Solution #2: Notification through composition for (Recipient x : recipients) { if (x instanceof Android) { sendAndroid(x, msg); } else if (x instanceof IOS) { sendiOS(x, msg); } ... }
12. Solution #2: Notification through composition for (Recipient x : recipients) { if (x instanceof Android) { sendAndroid(x, msg); } else if (x instanceof IOS) { sendiOS(x, msg); } ... }
13. Solution using Observer Pattern
14. Observer
15. Examples • Event Listeners • C# Delegates (register a function, and invoke it later)
17. Observer Demo
18. Oref (HFC) Devices
20. Monitoring- response time, errors App servers Autoscaling Logging
22. Logging Monitoring- response time, errors App servers Autoscaling
24. Logging Monitoring- response time, errors Application Servers (Mediator)
25. Mediator Pattern • Define an object that encapsulates how a set of objects interact. • Mediator promotes 
 loose coupling by 
 keeping objects from 
 referring to each other 
 explicitly.
26. Mediator- Structure
28. Relationship One-to-many vs. Many-to-many
29. Reusability
31. Responsibility
38. Possible Solution • Use enum that represents the current state / screen (watching, VOD menu, EPG, etc.) • Switch-case statement each time the user clicks on a multi-state button.
39. enum State { CHANNEL_INFO, TV, VOD, EPG, MENU, GAMES } class DigitalTVRemote { State m_state; public void menuButton() { ... } public void infoButton() { ... } public void exitButton() { switch (m_state) { case MENU: m_state = TV; showChannel(); break; case VOD: backButton(); break; case CHANNEL_INFO: m_state = TV; hideChannelInfo(); break; } } }
40. enum State { CHANNEL_INFO, TV, VOD, EPG, MENU, GAMES } class DigitalTVRemote { State m_state; public void menuButton() { ... } public void infoButton() { ... } public void exitButton() { switch (m_state) { case MENU: m_state = TV; showChannel(); break; case VOD: backButton(); break; case CHANNEL_INFO: m_state = TV; hideChannelInfo(); break; } } }
41. Solution using State Pattern
42. State Pattern- Motivation • An object-oriented State Machine. • Allow an object to alter its behavior at runtime when its internal state changes. The object will appear to change its class
43. State Pattern- Structure
44. State- Pros & Cons Pros: • Provides an easy way to change the behavior of a given object in runtime, based on its current state. • Adding a new state is very easy. Cons: • Many classes which are not part of the system design are added.
47. Strategy- Motivation • Defines a family of algorithms, encapsulate each one and make then interchangeable. • Lets the algorithm vary independently from the client that use it. • Choose the preferred algorithm to solving the problem, according to the current situation.
48. Strategy- Structure
49. Strategy- Pros & Cons Pros: • Provides an easy way to change the behavior of a given object in runtime, based on the current situation. • Adding a new algorithm is very easy. Cons: • Client must be aware of a different strategies. • Creates many classes which are not part of the system design directly.
51. State Changing who changes the state?
52. Encapsulation
53. When to use
54. Problem
55. Problem collection.sort(); collection.merge(c2); collection.find(x);
56. Iterator- Motivation • Provide a way to access the elements of an aggregate object sequentially without exposing its underlying implementation. • Provides a uniform interface for traversing different kinds of collections.
57. Iterator- Structure
58. Java Iterator public interface Iterator<E> { boolean hasNext(); E next(); void remove(); }
59. Java Iterator List<Integer> arr = new ArrayList<Integer>(); Iterator it = arr.iterator(); Integer i = it.next(); // for loop using iterator for (Iterator it = arr.iterator(); 
 it.hasNext(); it.next()) { ... } // Syntactic suger (foreach loop) for (Integer i : arr) { ... }
60. Internal vs. External Iterator • Internal- iteration controlled by the iterator itself. • External- client controls iteration by requesting the next element.
61. Complex data structures
62. Elements in the collection may be removed
63. Visitor
64. Problem
65. Solution using Visitors
66. Motivation • 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.
67. Structure
68. Visitor- Pros & Cons Pros: • Easy to add more services: just add a visitor class. Cons: • Hard to add a new class to the original hierarchy- need to change all the visitors!
69. Summary • Observer • Mediator • State • Strategy • Iterator • Visitor