The document provides an overview of behavioral design patterns, emphasizing their role in defining object communication and dynamic behavior using polymorphism. It discusses specific patterns such as Observer, Mediator, State, Strategy, Iterator, and Visitor, detailing their motivations, structures, and pros and cons. Overall, the document serves as a foundation for understanding how these design patterns can facilitate better software engineering practices.

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