1 / 22

“A labor of love” (Multicast Pattern)

“A labor of love” (Multicast Pattern). Chapter 4 (pages 112-131 or 123-144) Chris Gordon. Multicast Pattern. Described in the book as incomplete, work in progress, half baked, etc. What is multicast?. Its for event driven programming

morley
Download Presentation

“A labor of love” (Multicast Pattern)

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. “A labor of love”(Multicast Pattern) Chapter 4 (pages 112-131 or 123-144) Chris Gordon

  2. Multicast Pattern • Described in the book as incomplete, work in progress, half baked, etc

  3. What is multicast? • Its for event driven programming • “The flow of control is driven by external stimuli called events”

  4. Consider a vending machine A vending machine is just a very specific computer driven by various events

  5. How do we code this? • It can get very complex • Which objects use the events? • The answers can change even dynamically • Soon becomes a nightmare to code/maintain

  6. The vending machine can be represented as follows An event registry is a common solution:

  7. Event Registry • Two interfaces • One for events • One for event handlers

  8. Problems with event registry • Not type safe • Can leave hidden run-time errors • Bad!

  9. What should we do? • Blame someone else? • Give up and cry? • Multicast pattern!

  10. Details • Multiple inheritance • Each event has an abstract class • Each handler inherits from any events it can handle • Type safe!

  11. Details (continued) • How do the events get delivered? • Still need a registry, but need it type specific... • Register becomes exactly that, multiple type specific registries • Some debate over where this goes; seems to make the most sense in the event classes

  12. Structure • So here is our final structure:

  13. Participants • Message • Encapsulates information to be transferred from Sender to Receiver • Sender • Maintains a registry of Receiver objects. • Defines an interface for registering Receiver objects. • Defines and implements an interface for delivering a Message to registered Receiver objects. • AbstractReceiver • Defines an interface for receiving a Message object. • Receiver • Implements one or more AbstractReceiver interfaces. • Collaborations • Clients register receivers with senders through Sender's registration interface. • Senders instantiate messages and deliver them to registered receivers.

  14. Applicability • Objects want to receive info from other objects • Information is complex (it varies) • You want type safety (who doesn’t?)

  15. The big question • Is it really a type? • Seems to be just a special case of Observer • Should these details just be included in that pattern • Lots of questions involved in this issue • Is every observer really a multicast? • There are reasons patterns shouldn’t get too big • Strong/weak types play into this

  16. Intent • Very similar to observer • In observer the concrete observers vary • In multicast the events (messages) are the important variation • But it still sounds to similar

  17. Surprise! There’s a new pattern • After much argument, it was decided that Multicast is a refinement of observer called “Typed Message”

  18. Intent • Still very similar to observer • Encapsulate information in an object to add information without compromising type safety

  19. Motivation • Same as multicast • Event driven scenarios

  20. Participants (same) • Message (ProductDispensedEvent) • Encapsulates information to be transferred from Sender to Receiver. • Sender (Dispenser) • Maintains a reference to a Receiver object. • Implements one or more operations that involve sending a message to the receiver. • AbstractReceiver (ProductDispensedHandler) • Defines an interface for receiving a Message object. • Receiver (CoinChanger) • Implements one or more AbstractReceiver interfaces. • Collaborations • A sender instantiates a message and delivers it to its receiver. • A message is passive; it does not initiate communication with senders or receivers.

  21. Applicability • Objects want to receive info from other objects • Information is complex (it varies) • You want type safety (who doesn’t?) • Same as multicast

  22. Consequences • Type safety  • Supports implicit invocation when combined with observer ?? • Difficult without multiple inheritance  • Inheritance hierarchies get cluttered  • More flexible than observer 

More Related