oo_desc.txt

There are many ways to look at the object oriented paradigm, and in fact, the diversity of design approaches which fall under than banner is the direct result of people seeing OO differently at its inception.

The "simulation" view of OO is that objects are analogs of real world concepts or entities. We leverage OO to the degree that we are able to model them in software.  

The "data modeling" view of OO sees objects as an extension of entities in entity relationship diagrams.  We leverage OO to the degree that we are able to make objects which align with the structure of the data we need to manage in our applications.

The "computer science" view of OO sees objects as abstract data types which are are natural extensions of the primitive types we have in programming languages.  An Account is like an integer with higher level operations and a bit more state.

The "actor" view of OO sees objects as things which communicate with each other via messages much like cells do in biological systems. We leverage OO by favoring messages which tell rather than ask.  When we do this we arrive at systems which are extremely decoupled. 

In this workshop, we adopt the actor view to distinguish OO from the other paradigms.  Objects are not just packets of data and behavior bundled together, they are maximally independent nodes in a network.  Triggering events at one end of the network lead objects to send messages to each other until, at some point, messages are sent out of the network to have an effect on the world.

Dependency can never be completely eradicated in an OO system, however we can do things which minimize it and it make it much easier to "pull out" and "plug in" pieces.  It is important to note that return values induce coupling.  An object which receives a return value from its message send is now in a position to act in response to the object it sent a message to -- it is subtly dependent upon it.  If there is no return value, the object simply sits and waits for additional stimulus from objects which send it messages on their own behalf.  Dependencies are fewer and more explicit.  It is interesting to note as well that if we move to this return-less style there is nothing which keeps our messages from being asynchronous rather than synchronous.  We are able to reduce blocking within our systems.