Author(s)Keith Donald, Erwin Vervaet, Colin Sampaleanu
Signals the occurence of something an executing flow should respond to. Each
event has a string id that provides a key for what happened: e.g
"coinInserted", or "pinDropped". Events may have attributes that provide
arbitrary payload data, e.g. "coin.amount=25", or "pinDropSpeed=25ms".
For example, a "submit" event might signal that a Submit button was pressed
in a web browser. A "success" event might signal an action executed
successfully. A "finish" event might signal a subflow ended normally.
Why is this not an interface? A specific design choice. An event is not a
strategy that defines a generic type or role, its essentially an immutable
value object. It is expected that specializations of this base class be
"Events" and not part of some other inheritence hierarchy.
For example, a "submit" event might signal that a Submit button was pressed in a web browser. A "success" event might signal an action executed successfully. A "finish" event might signal a subflow ended normally.
Why is this not an interface? A specific design choice. An event is not a strategy that defines a generic type or role, its essentially an immutable value object. It is expected that specializations of this base class be "Events" and not part of some other inheritence hierarchy.