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.

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.

However, if you put the drawing code in the View, how does the View
query for the data?  It seems that virtually all of the Model's state
information needs to be made readable.  After all, some future View
design may need some piece of state that was not thought of earlier in
the design.  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.

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.