Re: designing beyond MV and (one) C

FROM : Ricky Sharp
DATE : Wed Jan 16 03:03:20 2008

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_removed>
Instant Interactive(tm)  http://www.instantinteractive.com