“A labor of love” (Multicast Pattern)

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 