1 / 17

Chapter 4. Labor of Love

Christopher Swope, Yuling Liang. Chapter 4. Labor of Love. 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.

orphas
Download Presentation

Chapter 4. Labor of Love

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 program’s 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 that’s 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 it’s 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 => Multicast • Narrow Scope => Observer

  13. 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…

  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 <Pattern Hatching> by John Vlissides

More Related