MVC in Cocoa: Another Steaming Pile
MVC in Cocoa: Another Steaming Pile
Join the DZone community and get the full member experience.Join For Free
MVC is not object oriented. It‘s not really a pattern either. To say ‘have one abstraction for your model and a different one for a view,‘ does not make you an OO practitioner, especially since multiple views are touching the same model (violation of central OO principles of data hiding, encapsulation, etc.). MVC is a great example of something that provides an ounce of clarity and then once you are a few feet down, becomes a pit of stupidity.
Even Cocoa, which is without a doubt, the best application framework I have ever used, falls into this pit. Last week, I wanted to transform a view into a grouped table view. First sign of trouble: you have to go find the part of the documentation that talks about what you want to do. Heuristic #1: what you want to do should be supported by, um, CLASSES!! :O But alas, it‘s not. The UITableView Programming Guide I have gone through 20x, so I found the spot fairly quickly. But the examples there are kind of minimal. Downloaded some example code. Didn‘t have corresponding custom cells for each of the groups so that was kind of useless. Eventually, got the thing to do just what I wanted, and it was not that much trouble. Then I wanted to move some things around. That‘s when I hit heuristic #2: if you are going to multiple places and changing #s to get a different look, your ‘view,‘ um, sucks. Long story short: you have to set the cell height (based on the indexPath), you have to populate the appropriate cell (based on the indexPath), you have to capture clicks (based on the indexPath). See the ‘pattern‘ here? I have a name for this pattern: anti. This name holds for all patterns that sell themselves as patterns and leave you employing practices that could give you a epileptic linear basic flashback if you‘re not careful.
How should this work? Gee, the long answer is that the Cocoa engineers should know that MVC is a joke and be using PAC instead. But I will just stay in the MVC world for a minute:
- make a class called UIGroupedTableViewController.
- put in a list of SectionControllers.
- each SectionController has a list of TableViewCellControllers.
- the TableViewCellController has a method onCreate.
Frankly, O-C doesn‘t have anonymous methods (until blocks are further integrated), but it would be cool to just declare the Cell controllers all in one place because then you‘d get the best of both worlds. You could accomplish that by making a Builder of course (no reason to do a Visitor here because there are only two node types, but that would get you there too). If you are thinking the containers could be a composite, there are only two node types. The only other challenge here is how you get the model into each of the cells. This is one of the great things about PAC: sometimes, there is a need for access to a shared model but a lot of times, components can just listen to events and update their own representational state. If you need a core abstraction, e.g. a restaurant, there are a number of ways to deal with that. One would be to have the builder construct do the wiring and then inject the components into the appropriate cell. That‘s probably the easiest. There is no need to get the values back out because the outer controller will have the save logic in it. Another option would be to have the cells all get an abstraction through a delegate method (this is one of the great things about delegates in general: mixins are simple and they are probably a central reason why there is no real need for dependency injection in O-C).
Why is this not there in O-C? I think this is a case of where the framework aims for 80/20 with the rule being if you are doing something really complicated, you can just do the work of making an interface abstraction (the A in PAC). And I am kind of sympathetic to this way of thinking. But, on the other hand, my attitude is that you are not doing object oriented programming if you are not showing extension through types (Open/Closed Principle).
I may take a swipe at this. In the meantime, the events and delegates mechanisms in Cocoa make the idea of doing PAC very appealing because the plumbing is already there.
Published at DZone with permission of Rob Williams , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.