From: Chris Gehlker <canyonrat@...>
Date: 2002-09-14T23:47:27+09:00
Subject: Re: MVC and OO Design?


On Friday, September 13, 2002, at 05:44 PM, MetalOne wrote:

> The Model View Controller Architecture has always had me a bit
> puzzled.
> As I understand it, when the Model gets updated, the Model notifies
> the Views that the Model has changed.  The Views then query the Model
> and draw themselves.
>
I understand the MVC architecture completely  differently. The nature 
of the model is that it never initiates behavior and that it is 
interface agnostic.

> Now since the Model has the data, the first obvious place to put the
> drawing code would be with the model and passing the View as a
> parameter.  However, if there are multiple ways the model might be
> drawn, say as a graph or as a chart, then maybe you don't want the
> drawing code in the Model.  After all, every time you want a new way
> to view the Model, you have to open up the Model code to add the
> class.  With this design the class is never closed.
>
Again the model doesn't have any knowledge of how it it being queried. 
It should be equally accessible from a GUI, a CLI or an automation 
language.

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

The controller queries for data.
> It seems that virtually all of the Model's state
> information needs to be made readable.

Yes, with the caveat that the controller doesn't really know whether  
the model is reporting or calculating. But don't store information 
about  the state of the user  interface in the model. Use controller 
hierarchies for that.
>  After all, some future View
> design may need some piece of state that was not thought of earlier in
> the design.

So change the controller.
>  Perhaps some of the state data can be determined to be
> private, and only the essential properties of the Model need public
> read accessors.  However, always making the Model's properties
> readable seems ugly to me.  Fortunatley, Ruby makes this much easier
> than other languages using attr_reader.  In Java, it just seems
> impractical.

I think this notion comes for you efforts to put too much in the model.

> This problem comes up more generally in OO programming also.  In
> general, a class will never have every method that a programmer can
> think of.  For example, a String class will probably not have an
> encryption function.  Thus string must expose its internal state in a
> read only fashion, to allow a future encryption function to be
> written.  In the case of String, it is easy to expose the internal
> state.  However, for more complex objects, it generally is not.
>
> Ruby does help this problem on two fronts.  First, you can just use
> attr_reader to make all state variables readable.
> Second, classes in Ruby are never Closed.  I could actually add an
> encryption function to the String class.  I don't know if this is
> wise.  The encryption function could leave the string class in a bad
> state.  It is nice to know that a class is Closed and is correct.
>
> I often feel the problem is easier to think about when objects are not
> involved.
> Show(Model, View).  The Show function needs data from the model and
> viewport information from the view in order to draw.  If these are
> just C Structs then there is no need to worry about accessors.
> However, this leaves no encapsulation of the Model's state data, which
> is bad.
>
> I guess my real questions are the following:
> 1) Under the MVC scenario, does it make sense to expose all of the
> model's data using attr_reader.  What if the code was written in Java,
> where getter functions would be required for all data?  Imagine a very
> complicated nested data structure that would require hundreds or
> thousands of lines to make readable.
> 2) Would it be better to add the draw functions to the model by
> opening up the model later.  Perhaps a view module could be created.
> This module would contain the code that opens the Model and adds the
> draw function or functions.
> What if you're using Ruby and can't open the class later, but you have
> to edit the only source for the class.  In my case the source is
> available, but conceivably, in general, it might not be.
>
> Any thoughts on this subject or good links would be greatly
> appreciated.
>
Just a general thought that you don't seem to have grasped the function 
of  the controller. Think of the model as a passive thing that only 
responds to messages. Think of the view as a passive thing that 
responds to user input. The model has the business logic but the 
controller has the program logic.
---
The higher we soar the smaller we appear to those who cannot fly.
-Friedrich Wilhelm Nietzsche, philosopher (1844-1900)