Re: designing beyond MV and (one) C
Re: designing beyond MV and (one) C
- Subject: Re: designing beyond MV and (one) C
- From: Uli Kusterer <email@hidden>
- Date: Mon, 14 Jan 2008 10:19:07 +0100
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
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden