Cortlandt,

> >The
> >resulting design can be simpler, because it does not require all the
> >possible combinations and sequences of incoming events to be
> specified, as
> >would be required in a conventional programming approach."
>
> I don't get it.   I don't see a difference here between event driven
> and conventional programming.  If the events are discrete then
> combination and sequence is irrelevent -- ergo requirements are the
> same.    For more complex logical events where combination or
> sequencing is important then all possible paths would still have to
> specified - ergo requirements are the same.


My interpretation was a bit simpler, yet different, but I agree with the
notion that all "possibilities (possible paths)" must be accounted for. I
think the author, Richard Pawson, is trying to emphasize the pricinple of
interdependence (also known as isolation). His point has to do with the
"cost of change". Conventional programming (or programs) often contain all
the code to handle 2-N events. So given an event (or more approriately, the
applications response to an event) must change - the changes should be made
with little or zero impact on the other parts of the application, and the
changes should affect a small footprint of code. Secondly the author is
attempting to introduce the notion of "bottom-up analysis and design" -
building blocks.

Jonathan van den Berg
Premier Software Technologies
fon: 408-257-8757
fax: 408-253-1184
www: www.premiersoft.com