[mattgreenrocks]

If you want it to look prettier on-screen you can just an editor with code folding and hide all the irrelevant functions.

Really, this is just a weird halfway house reminiscent of Rails' ActiveSupport::Concern. Much like that implementation, it encourages developers to address SRP by chopping the class up and calling it done. Difficulties in testing and reasoning are still in place, and the class is likely still too coupled.

If the local units are truly independent concepts, then they should be split out into their own objects. Either make smaller objects that either model the domain closer, or abstract away needless technical details. For example, any sort of serialization (web service/DB) should be hidden behind a high-level class that obscures how it's done if only to firewall the dependency itself from leaking it's conceptual garbage over the rest of your code.

This can be applied gradually with good effect. It's not an all-or-nothing proposition.

[mariodiana]

I'm completely on board with you when it comes to things like the serialization ("web service/DB") that you brought up, but I wasn't talking about that. I was specifically talking about view controllers managing table views.

If we're talking about table views and controllers, I'm not sure how to factor out the delegate and datasource in a convenient way. The delegate, in many cases, will need to know information contained by the datasource (the number of objects in a table view or table view's section, for instance).

How do you suggest it gets this information? Should it have a direct channel to the datasource? Should the controller act as an intermediary? Should it have some indirect channel to the information -- blocks or notifications or wired up in some kind of delegate relationship with the datasource? I haven't been able to find a good answer.

I actually fancy myself a bit of a nut when it comes to partitioning out my code into different objects, because I can't stand the mental overhead when one class does too many things. But I have come up with no solution that satisfies me when it comes to view controllers, because it seems like a lot of plumbing needs to be put in place. What I do know is that Apple itself, as well as several good sources on coding for Cocoa and Cocoa-Touch make extensive use of categories. I still think they can be put to good use in the situation I describe, but I'm open to alternatives.