Chapter 4' Labor of Love

1
Chapter 4. Labor of Love

• Christopher Swope, Yuling Liang

2
1. Introduction/Overview

• How does a Design Pattern evolve?
• Important because...
• Gives us a better understanding of design
  patterns
• Provides insight into thinking that takes place
  when authoring a Design Pattern

3
2.Motivation

• Event-Driven program
• If a programs control flow is governed by
  external stimuli called events.
• Real life example

4
2.Motivation(cont)

• Tentative Solution 1
• Registry
• Dynamic Cast in Handler
• Problems
• Not efficient,
• Not Type Safe

5
2.Motivation(cont)

• Tentative Solution 2
• Define an abstract classes for each type of event
• Classes interested in receiving events derive the
  abstract class, and register with the classes
  that send the event

6
3. Intro to Multicast

• Where to Register your interest?
• Register with Event Sender
• Register with Event itself

7
3. Reservations about Multicast

• Visitor could also be a solution
• What would be the limitations of this approach?
• Multicast isn't exactly perfect
• Might lead to many different classes
• What if the same event is generated by more than
  one class?
• How do clients know which classes generate
  events?
• What if you want to add a new event?
• Don't we already have a pattern thats pretty
  close to Multicast already?

8
4.Multicast vs. ?

• Multicast is very similar to...
• Observer
• (Supposed) Differences from Observer
• Observer is intended for one-to-many
  dependencies Multicast is motivated more by
  many-to-many dependencies
• In Observer, the subject and observer(s) are
  highly related In Multicast, senders and
  receivers are related by events
• In Observer, interaction between subject and
  observer is usually limited to notification In
  Multicast, interaction focuses on the (type of)
  information being passed
• But, are the patterns really that different?
• Could easily implement Observers for which these
  generalizations do not apply

9
5.Applicability

• Why use Multicast?
• Want to pass information from one class to
  another
• Don't want to constrain the information's form
  (i.e., type)
• Can't force the specialization of a specific
  class, for example
• Want the information transfer to be statically
  type-safe
• But what really makes Multicast different from
  Observer?
• For any particular situation, one might be more
  preferable than the other, but the two patterns
  seem interchangeable
• There's nothing that we could do with one that we
  couldn't somehow do with the other
• What makes a pattern, a pattern?

10
6. Scalability in Design Patterns

• Should a significant refinement and variation of
  a pattern be promoted as a separate pattern?
• How are Multicast and Observer related?
• Are they dependent? If so, must we roll them into
  one pattern?
• Is the one-to-many dependency of Observer useful
  by itself?
• Should every application of Observer also be an
  application of Multicast?
• Answer from Ralph

11
7.Intent

• Multicast's Intent Deliver information to
  interested objects at arbitrary times through an
  extensible interface
• What does this mean?
• While perhaps not its intent specifically, we
  could use Observer for this purpose

12
7.Criteria for New Pattern

• Wisdom about patterns comes from the space
  between them - Richard
• Space between Multicast and Observer is defined
  by the scope of the patterns
• Wide Scope gt Multicast
• Narrow Scope gt Observer

13
8. Opinions outside GoF

• Bob Martins point of view
• The intents of Multicast and Observer are
  different. Multicast cares about the type of
  event, Observer cares about the source of the
  event.
• Keyboard-vs.-Keypad example
• Erichs response and suggestion
• Agree, how about something named

14
9. Typed Message

• Structure of Typed Message

15
10.Sample Code of Typed Message

• Code from the book P133-134
• Events class defined handler class for itself
• The constructer of handler class register the
  handler automatically,
• Use template to enforce type safety

16
11. Conclusion

• Patterns are hatched, not discovered
• Influenced by particular perceptions and
  experiences of their authors
• If a variation isn't listed with a pattern,
  doesn't mean that it's not really a variation
• Probably just means that its a variation that no
  one bothered to write down
• Patterns don't always come out right the first
  time
• Patterns are highly related to other patterns

17
12. Questions?

• Reference
• All figures are from ltPattern Hatchinggt by John
  Vlissides