From: Jim Weirich Date: 2002-09-14T12:49:21+09:00 Subject: Re: MVC and OO Design? >>>>> "jcb" == jcb 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 jweirich@one.net 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)