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: Wed, 16 Jan 2008 02:31:37 +0100
On Jan 16, 2008, at 12:40 AM, Daniel Child wrote:
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.
Well, in practice it is often the case that a controller isn't very
reusable, but that's not a hard and fast rule. If your particular case
allows for a certain amount of genericness, it would be a shame to let
that opportunity go to waste and write special code over and over
again. The main advantage of OOP is that it makes it easier to reuse
code because it helps you structure it in reusable packages. But OOP,
MVC and all the rest of the alphabet soup is there to serve you, not
the other way round :-)
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.
The point is just that the window controller takes care of certain
tasks for you. Of course, I can't think of a single one right now, but
it does. I usually mainly use it together with NSDocument, so it'll
probably come to me the moment I turn off the computer...
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