Actually, I want to create a networking-aware view controller, than will have some network-ready functions such as asynchronous get from server, and analysis of the data. I could just subclass NSViewController, but that would mean that I should also subclass NSTableViewController and write similar if not the same code for it, too.
I'm not sure I understand what network-ready functions would be appropriate for a view controller. A controller mediates between Model and View. To me, that suggests any network-ready functions should be in either the Model, because the Model is network-aware, or the View, because the View is network-aware. But I'm not sure what it would mean for a View to be network-aware, so that just leaves the Model.
If there's an async get from server or analysis of data, that seems to me like it all belongs in the Model. The Controller tells the Model
when to do something, or asks it for
what to present in the View, but I don't see the Controller needing to know
how the Model does its thing. Being network-ready implies a
how (the
how being "over the network", and to me, all
how's involving data are the responsibility of the Model.
Maybe your controller class is also acting more or less like a Model. That happens, especially if the data in the Model is relatively simple. But if you're considering a solution that involves retrofitting methods and variables to multiple predefined NSXyzController classes, then I think that's a clue that it's time to factor out the Model into a separate class or classes. It may also be a clue to review the
MVC documentation.
The touchstone I use to decide whether something should be in the Model or the Controller is "Could I write an ncurses version of this program, and reuse the Model classes without change?" If there is any data-handling logic in a Controller class, then the answer will be "No", because I'd need to rewrite or refactor the functionality of that Controller to make the program work in ncurses. However, if I can replace the Controller(s) with new classes that handle ncurses-style interaction, then I know the Model has been properly factored out from the Controller. Ncurses knows nothing about nibs or NSViews. It's a classical terminal-handling library.
To further check my factoring of the Model, I ask myself whether I can write a version of the program using only command-line options as inputs. Again, that takes a completely different kind of Controller (and "View"), but if the Model can be used unchanged, then it's usually a good factoring.
Finally, I'm not aware of a NSTableViewController class on Mac OS X. There's a UITableViewController, but it only exists on iOS. So maybe your question is really better suited for the iOS Developer forum. If so, please say that, so this thread can be reported to the mods for moving to that forum.
And frankly, I'd suggest the same thing when targeting iOS. If you're considering adding methods and ivars to a predefined class, you should probably revise the relationship between the Controller and Model.