Re: designing beyond MV and (one) C

FROM : Uli Kusterer
DATE : Mon Jan 14 10:19:07 2008

On 12.01.2008, at 23:39, Daniel Child wrote:
> I'm building a utility to take various types of data and parse them 
> according to my settings. I'm looking to have an introductory window 
> that asks what type of file the user wants to parse. Then based on 
> the response, I open the appropriate window to gather data about the 
> file to be handled. Separate interfaces will be used for the 
> different types of parsing operations.
>
> In the MVC paradigm, do you typically use a different controller for 
> each major interface? Should I have three controllers, one to handle 
> each type of parser? Three window controllers, to handle each major 
> settings interface?



  I do whatever 'feels best'. Generally, that means that I often 
wiggle along with dumping all in one file for simple projects, unless 
I know I'll want this to grow. If I know that my app will be bigger in 
the end, I generally break it up early on (generally, that means 
before this version ships, or if I know that this small version is 
just there because I want to ship a few intermediate releases before I 
get this feature completed, but my road map already has the bigger, 
more complex version on it).

  For the case you mention, it sounds like you could get away with a 
pair of controllers or so. The idea is that you have one (generic) 
class that encapsulates all the features that all the parsers expose 
to the GUI. The GUI, and any of its controllers, only know how to talk 
to this generic controller. The actual parsers would then be 
subclasses of this generic controller. Only the spot that opens the 
file would need to know what type of file it is, and would create the 
appropriate subclass.

  The rest of the app would just talk to the subclass through the 
generic controller's interface. If there is only one window, one 
window controller would be enough. If you only have very, very simple 
windows, and you don't open several instances of the same window, you 
may even get away without a window controller and just hide and show 
the windows as needed.

  Just saying that's possible. Having many controllers and many 
classes is a useful thing, if you can find the right boundaries to 
split your functionality at. When I'm not sure, I sometimes create one 
huge class until I see patterns developing, and then I split out small 
sub-controllers for the various parts until the main class has a 
manageable size again. If you split at the wrong boundaries, all you 
get is a icky mass of objects constantly looking at each other's 
variables or forwarding messages between each other. Forwarding 
messages is not unusual in an MVC design, but if you have too much of 
it, it becomes unmanageable.

  So, three window controllers don't sound like a bad idea at all. If 
you're new to this, I suggest just doing little prototypes that try 
different approaches and see which one works best for your problem 
domain. As someone else mentioned, few controllers means you'll have 
lots of switch statements or ifs looking at what object called you. If 
that's the case, you may want to split each "if" case out into its own 
controller. Whether that's a hand-rolled controller or a standard 
NSArrayController.

  You can have one big "master controller" that owns these window 
controllers (in document apps that's often the document, but in your 
case it could also be a class of your own, or your application 
delegate, or a helper object your app delegate talks to, or whatever 
makes sense and keeps your source files at a manageable size).

Cheers,
-- M. Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de