Re: designing beyond MV and (one) C
Re: designing beyond MV and (one) C
- Subject: Re: designing beyond MV and (one) C
- From: Ricky Sharp <email@hidden>
- Date: Tue, 15 Jan 2008 20:03:20 -0600
On Jan 15, 2008, at 7:31 PM, Uli Kusterer wrote:
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 :-)
For what I do, subclassing controllers was the way to go. In my full-
screen app, each of my "screens" is represented by a nib containing
the UI. The nib's owner is then a subclass of IIScreenController.
The base class has quite a bit of stuff in there. For example,
building up a language model for speech recog for the current screen
by walking the custom UI and looking at everything that implements my
IISpeakable protocol. No code was necessary in any subclass for
speech recog.
Some subclasses contain very little code, especially for those screens
where bindings could be used for 100% of the implementation. In other
cases, there's large amounts of custom code which deals with the
unique business logic for a particular screen.
My screen-loading code is then in my main app controller. There, I
load screens via names which can be built up dynamically (no need to
maintain say a massive switch block). Thus, every time I need to add
a new screen, I just create a well-named nib and controller subclass.
Code to move to a new screen is simply [self
pushScreen:@"MyNewScreenName" parameters:aDictionary]. And, I can
really drop that code anywhere. Thus, if I want to provide a link to
"ScreenB" from two or more places, I can do that with just one line of
code. I pass parameters from screen to screen using a dictionary.
Thus, there was no need to implement custom API entry points with
varying parameters in each subclass. There's only a single API entry
point that just takes a dictionary.
Just wanted to add that last paragraph to also show that you can write
your code to be extremely extensible with very little effort. In past
frameworks, I've often had to write extra code to "wire in" any new
subclass I would create. And, going back to the speech-recog example,
as I add/edit new UI elements, I can simply set their speakable*
property in IB (phrase to use) and I'll end up with a properly built
language-model at runtime. No code to write; very extensible and
maintainable.
* No such property yet exists for Aqua controls; all my UI is custom
and therefore I created IB Plug-ins to edit them.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
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