From: Chris Gehlker <canyonrat@...>
Date: 2002-09-17T12:46:51+09:00
Subject: Re: MVC and OO Design?


On Monday, September 16, 2002, at 03:32 PM, MetalOne wrote:

> I was really thinking very abstractly about a problem in my head that
> MVC kind of demonstrated.  I was in search of deep answers in regards
> to when to include a function in a class and when not too.  The common
> wisdom states that when a function needs access to the classes data,
> it should be included with the class.  MVC strays from this notion
> because the View needs access to the Models data and yet the View
> functions are not placed in the class.  Abstractly, any function could
> be thought of as a view function, even if it does not draw a
> representation of the object.  This could lead one to conclude that if
> a function does not change an object's state, then it should always
> reside outside the object and query the object for data, just like a
> View object.  Fat classes generally are not considered good design, so
> I was trying to envision what it would be like to have very thin
> classes, containing only functions that modify state.  Writing all the
> accessors seemed awkward though.  I suppose as always there are no
> hard fast rules and comprises are required.
>
It's a tough problem and I'm not sure there is one style that works for 
all languages. My C++ classes are very thin and I can tell you why 
every member function couldn't have been implemented without access to 
the object's state. My Ruby and ObjC classes tend to be fatter. Why? I 
suppose it's a combination of making membership serve some of the 
function of namespaces, for ObjC, and some feeling that the contract is 
just different in languages where classes are closed as opposed to 
those where they are open. I keep half expecting all my Ruby and ObjC 
code to come crashing down because encapsulation is more like a 
membrane than a wall. So far it hasn't happened though. It's as if it's 
enough to describe the safe interface to a class without  requiring the 
language to enforce the exclusive use of that interface.

> The responses above brought me back to a more concrete reality. MVC is
> there to separate out user interface code.  It is also true, that I
> did not understand the roll of the controller.  Thinking of a passive
> Model and a passive View has also helped me with my current problem.
>
> Perhaps it is wise to pull functions out of a class along functional
> lines that require specialized developer skills such as GUI, Database
> Access, Encryption, etc.  Or maybe it only makes sense for GUI,
> because, of the need to easily change the GUI.
>

I think you are on to something here.
-- 
We are all born originals - why is it so many of us die copies?
-Edward Young, poet (1683-1765)