Chap 4 Presentation

17
Chapter 4. Labor of Love Christopher Swope, Yuling Liang

Transcript of Chap 4 Presentation

Page 1: Chap 4 Presentation

Chapter 4. Labor of Love

Christopher Swope, Yuling Liang

Page 2: Chap 4 Presentation

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

Page 3: Chap 4 Presentation

2.Motivation

Event-Driven program – If a program’s control flow is governed by external stimuli called

events. Real life example

Page 4: Chap 4 Presentation

2.Motivation(cont)

Tentative Solution 1– Registry – Dynamic Cast in

Handler– Problems:

Not efficient, Not Type Safe

Page 5: Chap 4 Presentation

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

Page 6: Chap 4 Presentation

3. Intro to Multicast

Where to Register your interest?

– Register with Event Sender

– Register with Event itself

Page 7: Chap 4 Presentation

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?

Page 8: Chap 4 Presentation

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

Page 9: Chap 4 Presentation

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?

Page 10: Chap 4 Presentation

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

Page 11: Chap 4 Presentation

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

Page 12: Chap 4 Presentation

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

Page 13: Chap 4 Presentation

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…

Page 14: Chap 4 Presentation

9. Typed Message

Structure of Typed Message

Page 15: Chap 4 Presentation

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

Page 16: Chap 4 Presentation

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

Page 17: Chap 4 Presentation

12. Questions?

Reference

– All figures are from <Pattern Hatching>

by John Vlissides