1. Event Architectures & Design with Composition Elizabeth Bigelow CS 15-499C Computer Science Carnegie Mellon University October 9, 2000

2. Today’s Lecture Reminder of schedule Event Architectures Design with Composition “Coad Patterns” With this lecture we switch to implementation

3. Schedule Wednesday: Teams D, E, F presentations Friday: mentoring sessions. Teams unable to have all members present must complete mentoring sessions by Monday

4. Event Architectures General Theory What are they? What are they good for? When are they not indicated? Java implementation

5. Event Architectures Most familiarly, systems with interfaces of procedures interact by explicitly invoking those routines. Event architectures use implicit invocation (reactive integration or selective broadcast)

6. Implicit Invocation Component (or object instance) can announce or broadcast one or more events Other components (or object instances) can register an interest in an event by associating procedure with it. When the event is announced, the system itself invokes all of the procedures that have been registered for the event

7. Some fine points Announcers of event do not know which components will be affected by those events No assumptions can be made abougt order of processing or even whether processing will occur

8. Advantages of approach Strong support for reuse and change Eases system evolution

10. Disadvantages Components or object instances relinquish control over the computation performed by the system Exchange of data—unless passed with the event, global performance and resource management can become big issue with shared repository Reasoning about correctness may be difficult

11. When to use When processing of an event does not absolutely have to be guaranteed When notification needs to be very selective for performance reasons When processing of an event is not particular time critical (background process perhaps OK) Example – wish lists—change of price of an item or closeout sale—order doesn’t matter a great deal, nor would it be earth-shaking if it didn’t happen at all

12. When not to use Don’t use as substitute for procedural flow of control. Don’t use in safety or time critical systems

13. Java, ORB implementations Java has classes built in for propagating and registering events Java also allows listener to find out origin of event CORBA implementations have event handlers (almost always) but vary in how they accomplish it

14. Modeling Event Systems Depends on whether you need an explicit event handler (In architecture diagrams, this is often abstracted away) What you don’t want to do is try to model associations from originating classes to listener classes Keeping track of event/interest pairs is best done in a table or supplementary note material

15. Design with Composition In early object orientation, inheritance was the only tool for extending responsibilities Mature object design though finds extending responsibilities with inheritance is applicable only in very specific contexts And in Java, multiple inheritance is prohibited in any event Note that using inheritance on a conceptual model is ok for clarifying thinking—but that refinement for implementation requires the move to composition

16. Guidelines Use composition to extend responsibilities by delegating work to more appropriate objects Use inheritance to extend attributes and methods (but only when it doesn’t hurt encapsulation)

17. Strategy Use composition to extend responsibilities by delegating work to other objectrs Containment is a special type of composition—objects inside are hidden from outsiders

18. Example PassengerReservation1o..*

19. Inheritance Mechanism for extending the responsibilites defined in a class—take defined attributes associations and methods and add to them in some way Subclass inherits everything that is defined in its superclass, accepting the superclass’ definitions as its own

20. Inheritance vs. Interfaces Inheritance extends implementation of a method, not just its interface Interface establishes useful sets of method signatures, without implying an implementation of a method Java distinguishes between inheritance and polymorphism with different syntax C++ has single syntax—blurs distinction

21. Inheritance benefits Captures commonalities among attributes, method signatures and methods Kinds of roles, kinds of transactions, kinds of things Very nice and neat intellectually

22. Risks Strong encapsulation with other classes but weak encapsulation between a superclass and its subclasses What happens when you change a superclass?

23. Risk Mitigation Make class hierarchy very cohesive (not factoring out of method implementations or role played by superclass Make sure that superclasses are realy extensions

24. Risk #2 Inheritance connotes weak accommodation of objects that change subclasses over time Every time an object in one subclass needs to change into an object in another class, you have to create the object in the other class, copy values to new object and then delete the new object Better—use composition of roles to get around the risk

25. Almost always use composition But the exceptions are (always use checklist) “Is a special kind of” not “is a role played by a” Never needs to transmute to be an object in some other class Extends rather than overrides or nullifies superclass Does not subclass what is merely a utility class Expresses special kinds of roles, transactions or things

26. Coad Patterns One of Coad’s greatest contributions to object modeling is the concept of domain neutral components (structural pattern which occurs over and over again) He has quite cleverly found a way to make object models clearer by combining color with “archtypes”

27. Coad observed That classes tend to have four categories (especially in information systems) PartyPlaceThing > green Description > blue Role > yellow (a way of participating in something MomentInterval >pink— a moment in an interval of tije that you need to track or do something about—often has details

28. Why are these useful? Almost every information system starts out with these patterns Helps clarify thinking about what to include in a particular class In particular, the moment interval and details help clarify thinking. Over what time periods do I need to record information? What details do I need to keep (if any?)