[racket] Whither ProfessorJ

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/