Re: designing beyond MV and (one) C

FROM : Daniel Child
DATE : Wed Jan 16 00:40:38 2008

On Jan 14, 2008, at 4:19 AM, Uli Kusterer wrote:
>  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.

I didn't think of subclassing from a "generic controller." I thought 
that the controllers are the least rewritable code, and therefore not 
generally subclassed. Now the model code for the different parsers... 
they have enough in common, I think, to justify subclassing.

>  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.

I have been doing the latter, and am still trying to figure out what 
advantage there is to a window controller. What can it do that a 
regular controller can't, and vice versa....? I'm still failing to 
see their whole reason for being in non-document app cases.

>  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).

I'll give that a try too, once I figure out the window controllers. 
Thanks.