Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Alan Lovejoy <alovejoy@concentric.net>]

Nick Thurn wrote:
> 
> Alan Lovejoy (alovejoy@concentric.net) wrote:
> >
> > My usage of the word "design" in the quote above is being interpreted in a way
> > other than I intended.  In the context of the earlier posts, it should have been
> > clear that by "design" I was referring to the objects that exist when the program
> > runs, and how they interact.  And I was **defining** the term design as I had
> > used it, not trying to suggest that the implementation technology is not important,
> > or that one should not consider such issues when producing a design or implementing
> > a system!
> >
> Alan,
> 
> These objects interpreted (compiled at runtime) or otherwise are
> surely the products of implementation. You seem to presuppose an implementation
> which leads to a design, isn't this backwards?
> 
> The objects that exist when the program runs are a mixture of implementation
> objects, domain objects, library objects, ui objects, comms... etc. Trying to
> think back from them seems very unhelpful. IMHO even thinking *forward* to
> these implementation objects too early is dangerous.
> 
> Do you mean this or do I have it wrong?

Pardon me, I see I wasn't clear.  The "dynamic model" or "dynamic design" **deals with**
or **is concerned with** the objects that will exist at run time, what roles they will
play, what responsibilities they will have and how they will interact.  Of course the
run time objects are NOT themselves the design (in spite of the fact that my imprecise 
wording might give one the impression that I was saying that).

Many objects that exist at run time may have internal mechanisms that you have no
control over, such as those that may be instantiated from classes in the standard
library.  You can of course always choose not to use such "standard" or "system"
objects, and in some languages (such as Smalltalk) you may be able to easily change
them, but simply using them as-is is what usually happens.  You don't need to design
such "standard" objects, but you do need to know how to interface to them, and 
decide what roles (if any) they will play in your system.

Perhaps a concrete example will clear up the confusion.  The Model-View-Controller
concept is now familiar to many, so I will use that as the example.

The inventor of MVC (Trygve Reenskaug) calls the MVC architecture an example of what
he calls a "role model."  A role model specifies what objects collaborate together
in the "role model," and what the role of each object is in the collaboration.

The MVC "role model" specifies that there are three objects, a "model," a "view" and
a "controller" that collaborate in an MVC "role model."  The objects are named according
to the role that each plays.  It may be that more than one object will play the same
role as another, but that does not happen in the basic case of the MVC role model. It
may also be that the same object will play more than role, perhaps because it is also
a collaborator in a different role model.  Complex designs are constructed by composition
of multiple role models.

The responsibility of the "view" in the MVC role model is to graphically display informaition
about the state of the model. The responsibility of the controller is to get and respond to 
user input. The responsibility of the model is to maintain displayable state.  A formal
role model would specify the messages each object in the role model will send to the
other objects, what events would prompt the sending of such messages, and what the semantics 
of those message are.

The collaborating objects in a role model are understood as instances, not classes.  And a 
role is a function of a) the responsibility of an object and what purpose it serves, b) the 
messages that it will be expected to respond to (which might well be a subset of all the 
messages it could respond to), and c) the messages it will send to other collaborators
(which might not be all the messages it could send, nor all the receivers to which it may
potentially send messages).  The MVC role model does not just say that there are models,
views and controllers, and that they send certain messages to each other.  It specifically
says that a particular model, a particular view and a particular controller must collaborate
together.  The view can't collobarate with just any model it happens to find in memory.
It becomes associated with a particular model and controller, and collaborates with those
particular objects.  Object identity matters, and is explicitly dealt with.  If you want
to dynamically change which model the view and controller are associated with, that change
has to become part of the protocol specified by the role model.

From this it should be clear that roles are not classes.  One can use multiple inheritance,
dynamic typing with polymorphism, interfaces or dynamic delegation in order to put any object 
into one of the roles.  It just has to correctly respond to all the messages specified by the
role, and send only those messages allowed by the role.  This is of course easier to do
in a dynamically typed language, but it can also be done in statically typed languages
that support interfaces or multiple inheritance.

I wholeheartedly endorse role modelling, and recommend doing it **before** trying to worry
overmuch about the class hiearchy.  Wouldn't it be nice to identify the role models in which
the objects in your program will participate before designing the class hierarchy that will
provide the classes whose instances can be collaborators in those role models?

--
Alan L. Lovejoy		|==============================================| 
Smalltalk Consultant	|	Beware of Geeks bearing GIFs!	       |
alovejoy@concentric.net |==============================================|