Transcript Event Architectures & Design with Composition

Event Architectures & Design
with Composition
Elizabeth Bigelow
CS 15-499C
Computer Science
Carnegie Mellon University
October 9, 2000
Today’s Lecture
Reminder of schedule
Event Architectures
Design with Composition
“Coad Patterns”
With this lecture we switch to
implementation
Schedule
Wednesday: Teams D, E, F
presentations
Friday: mentoring sessions. Teams
unable to have all members present
must complete mentoring sessions by
Monday
Event Architectures
General Theory



What are they?
What are they good for?
When are they not indicated?
Java implementation
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)
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
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
Advantages of approach
Strong support for reuse and change
Eases system evolution
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
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
When not to use
Don’t use as substitute for procedural
flow of control.
Don’t use in safety or time critical
systems
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
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
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
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)
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
Example
Passenger 1
o..* Reservation
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
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
Inheritance benefits
Captures commonalities among
attributes, method signatures and
methods
Kinds of roles, kinds of transactions,
kinds of things
Very nice and neat intellectually
Risks
Strong encapsulation with other classes
but weak encapsulation between a
superclass and its subclasses
What happens when you change a
superclass?
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
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
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
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”
Coad observed
That classes tend to have four categories
(especially in information systems)
PartyPlaceThing <<thing>> green
Description <<description>> blue
Role <<role>> yellow (a way of participating
in something
MomentInterval <<moment-interval>>pink—
a moment in an interval of tije that you need
to track or do something about—often has
details
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?)