Re: MVC and OO Design?

>>>>> "jcb" == jcb  <[e-mail]> writes:

    jcb> The Model View Controller Architecture has always had me a
    jcb> bit puzzled.  [...]

    jcb> [... putting drawing logic in the model, not a good idea
    jcb> because...] every time you want a new way to view the Model,
    jcb> you have to open up the Model code to add the class.  With
    jcb> this design the class is never closed.

Exactly, the purpose of splitting out the Model and View is to
separate the business logic (Model) from the display logic (View).

    jcb> However, if you put the drawing code in the View, how does
    jcb> the View query for the data?

Generally Model classes are written with Views in mind.  The Models
don't know the details of the logic within the Views, but it is the
responsibility of the Model to give the View enough information to do
its job.  Providing public accessors is one way (and probably the
simpliest), but there are others.

Ignoring the Controller for now, the Model/View pair is essentially
the Observer pattern.  There are two basic approaches to observable.

The first is the "pull" model.  So named because whenever the Model
changes, it sends a simple notification message to the View.  The View
then pulls the needed data from the object by querying it.  This works
great for simple models with a handfull of attributes.  But what if
the model contains dozens of separate fields.  The view would have to
run through each of the individual fields to find the one that
changed.

Another way is the "push" model.  Whenever the model changes, it sends
only the changed data to the observer.  The data is somehow "tagged"
with identification so that the View knows what kind of data is being
sent.  An interesting variation is to "tag" the data with a command
object (the View just invokes the command object).  I've got a writeup
on the Observer Pattern and MVC at...

    http://w3.one.net/~jweirich/development/talks/patterns/observer.html

Its in Java though ... no Ruby version (yet!).

    jcb> It seems that virtually all of the Model's state information
    jcb> needs to be made readable.

Not all ... just what the View needs.  Generally the Model is written
with knowledge at a View will be using it and the Model designer
arranges that the needed data is available.

    jcb> This problem comes up more generally in OO programming also.
    jcb> In general, a class will never have every method that a
    jcb> programmer can think of.

Its impossible to completely predict how an object will be used.  I've
learned over the years to provide what's needed today, but keep the
code flexible enough so that new stuff can be added with little
effort.  To me, it is more important to be flexible than complete.

    jcb> 1) Under the MVC scenario, does it make sense to expose all of the
    jcb> model's data using attr_reader.  [...]

Make available what you need today.  If you need more tomorrow, just
add it.

    jcb> [...] Imagine a very complicated nested data structure that would
    jcb> require hundreds or thousands of lines to make readable.

I would move to a push model in this case.  Still, hundreds (let alone
thousands) of accessors seems excessive.  It may be time to refactor :-)

    jcb> 2) Would it be better to add the draw functions to the model by
    jcb> opening up the model later.  Perhaps a view module could be created. 
    jcb> This module would contain the code that opens the Model and adds the
    jcb> draw function or functions.

No, the draw logic does not go into the Model.

    jcb> Any thoughts on this subject or good links would be greatly
    jcb> appreciated.

Take a look at the observer pattern library in the Ruby distribution.

I hope this helps.

-- 
-- Jim Weirich     [e-mail]    http://w3.one.net/~jweirich
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct, 
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)