chap 4 presentation
TRANSCRIPT
Chapter 4. Labor of Love
Christopher Swope, Yuling Liang
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
2.Motivation
Event-Driven program – If a program’s control flow is governed by external stimuli called
events. Real life example
2.Motivation(cont)
Tentative Solution 1– Registry – Dynamic Cast in
Handler– Problems:
Not efficient, Not Type Safe
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
3. Intro to Multicast
Where to Register your interest?
– Register with Event Sender
– Register with Event itself
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 that’s pretty close to Multicast already?
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
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?
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
7.Intent
Multicast's Intent: “Deliver information to interested objects at arbitrary times through an extensible interface”– What does this mean?– While perhaps not it’s intent specifically, we could
use Observer for this purpose
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 => Multicast Narrow Scope => Observer
8. Opinions outside GoF
Bob Martin’s 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– Erich’s response and suggestion
Agree, how about something named…
9. Typed Message
Structure of Typed Message
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
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
12. Questions?
Reference
– All figures are from <Pattern Hatching>
by John Vlissides