Cocoa does not use the traditional notion of MVC.
All documented here very clearly
MVC as a Compound Design Pattern: https://developer.apple.com/library/ios/documentation/genera...
"The controller object in this compound design pattern incorporates the Mediator pattern as well as the Strategy pattern; it mediates the flow of data between model and view objects in both directions. Changes in model state are communicated to view objects through the controller objects of an application."
For example, if you have a view controller handling a table view that makes use of many delegate and datasource methods, it's easy to have code spilling all over the place. But you can use extensions and categories to separate out the delegate functionality into its own set of files, and do the same for the datasource as well. If you share the header files among the files, then to the computer it all works like one big class. But to the programmer -- and this is the whole point -- the functionality is broken out into conceptual units.
What you end up with is still a "god class," but instead of being monolithic, you wind up with a god of many faces. (I'm whimsically calling it the "Brahma" pattern.) Anyway, I suggest people give it a try if they've been having trouble organizing their code.
Does anyone on here have experience organizing their Cocoa apps this way? I'd be interested in hearing your input, since I've just gotten around to looking into this myself.
In this project I have one reusable ViewController (among others, but this example is about this one) that had nothing but a UITableView and a search box (a UITextField for searching by text, and a segmented control that sorts/filters the data by preset values like A-Z or distance).
About halfway through this project I found myself with a controller with several if/else blocks and other weird things to stop code re-use and make the controller abstract in the sense that I could init it with whatever data object I needed and it would figure everything else out from there. This accomplished my goal of limiting code re-use but it absolutely sucked when a change had to happen. Conceptually, it was terrible to go down and find the correct "else if {}" to make my amendments to and then make sure that didn't take anything else down with it.
Then I said to heck with code re-use. I'm going to make this sucker clean and easy to find/fix/edit/create a new one. I pulled all of my UITableViewDelegate and UITableViewDataSource code into separate files depending on the data model that was necessary for this controller. I still init the Controller the same way, but now all of the searching/sorting/table actions that were horribly done earlier are in their own separate classes - specific to the model for each.
This means that I have 12 files that have a slightly similar structure - all of the numerOfRows and cellForRowAtIndexPath type methods as well as my custom search view's delegates. And yes, an earlier self would of been a little weirded out by such blatant disregard for reuse. But yesterday, when a change request came in to add another similar type view with a different API and data model it literally took me 5 minutes to subclass my XXDataSource class and hook it up to a model, and the whole thing worked perfectly. 5 minutes. I can't tell you how good it felt to not have to look through the cruft and add another "else if" check and make sure my other stuff would still work.
I hate to call it beautiful since I'm still a noob, but damn is it beautiful. My controller has 40 lines. Each XXDataSource class has about 100-150ish. I highly recommend this approach, especially when it looks like you're going to reuse a tableview-esque controller.
Now my XXNavigationBrain solution - that's a whole other topic. ;)
My average controller is between 200 and 400 lines of code. This might be a lot of code in Rails of other frameworks but I find it acceptable in Objective-C (considering it's an extremely verbose language).
To reduce the lines of code in my controllers I usually use categories or subclasses for custom views (I don't use Interface Builder). You can also make manager objects to do most of the workload and reduce the lines of code per method. I think reducing the lines of code per method is more important than reducing the lines of code overall.
Things that I configure once and don't plan to touch again I put in separate files like subclasses or categories. Things that can change or are necessary for understanding the big picture stay in the controller. And guess what? Data Sources and Delegate Methods are necessary for understanding how a UITableView works. In my case 200 to 400 lines of code (on average) seems like a good compromise.
If you put the delegate and datasource in a separate file at least makes your controller look a lot cleaner but still there's still so much stuff going on in them that doesn't separate well. If you feel the need to add #pragma, categories and that kind of things to make your code more manageable the underlying code violates the single responsibility principle.
I tend to not use UITableView unless I need either the performance or I am using a lot of built in stuff and there's no fancy stuff going on. Having to know up front what the height will be of a yet to be rendered cell really leads to a lot of ugly code quickly. I will not use it if I simply want to repeat some items vertically.
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.
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.
