IMHO, a good perspective on OO is to think first that behavior emerges
from the *interactions* of objects. (Which perspective also has
implications for OOPLs, IMHO.)
Very-very-very simple embedded systems, like their model of a
coffeemaker (which doesn't even need to be an embedded system) make an
example of this almost too easy.
More important than the ``objects'' here is the ``state modeling'',
which predates OO in the discipline.
This coffeemaker example walks people through some of a process, but
doesn't do a great job of convincing that this hairy-looking process and
work product is better than a few lines of imperative code that one
could just whip out. You need the reader to either be an intelligent
person who temporarily suspends judgment, or to be a Java grunt who
always just goes through whatever motions they're told to go through.
Incidentally, embedded systems provide a particularly good example of
needing to address concurrency issues in your OO model.
Raoul Duke wrote at 01/18/2012 03:32 PM:
on the other hand, there exists a significant OO camp that - at least
to my simple mind - makes a decent argument for starting with the
behaviour/mu, not the data/nouns. small ex. cf. e.g.
http://www.objectmentor.com/resources/articles/CoffeeMaker.pdf
--
http://www.neilvandyke.org/
____________________
Racket Users list:
http://lists.racket-lang.org/users
