Sunday, August 05, 2007

A little clarity

Alrighty then. Got my Rainbow programlet working, using what I would consider to be as strict an adherence to MVC theory that I know how to do at this time. And there *cough* may or may not have been a typo that prevented it from working properly the first time around (== is not the same as =). I'm quickly learning that NSLog is my friend.

So now that I've proven to myself that it can be done, I'd like to get some additional thoughts on which approach to take. I'll compare what I'm calling "Pure MVC" to what I'll called "Muddy MVC."

-- Pure MVC --

The following classes are declared:
Color (model)
RainbowArray (model) (subclass of NSMutableArray)
AppController (controller)
NIB/NSTableView (view)

AppController is the NSTableView's data source and delegate, with corresponding methods implemented. AppController basically redirects those method calls to RainbowArray, where I had to override/re-implement a couple of NSMutableArray's methods like count.

-- Muddy MVC --

The following classes are declared:
Color (model)
AppController (model-controller, maybe even a little viewy)
NIB/NSTableView (view)

AppController is the NSTableView's data source and delegate, but this time the array of Colors (rainbow) exists only within AppController.

-- Pros and Cons --

Please feel free to add commentary.

Pure MVC
- more files (at least in this case) to keep track of
+ but those files each have a specific purpose, so they should be smaller or at least easier to read/organize
+ MVC theorists say that this supports re-use of the code
- Seems like a lot of tangible work now, in exchange for a possible savings later. I might value this more when I have a larger collection of code.
- More method calls (I think). The TableView will call AppController (msg #1) for a count, AppController will pass that along to RainbowArray (#2), RainbowArray will respond to AppController (#3), which will respond to the TableView (#4). #2 and #3 would not happen in Muddy MVC, so it seems to me this would almost have to be faster than the Pure MVC case.

Muddy MVC (pretty much the opposite of previous points)

So my thinking at this time is that the Muddy MVC approach is better for my purposes, mostly just based on my perception of performance (fewer messages). Any thoughts? I think for the time being I'm going to leave my mileage program as-is (muddy), unless I see a really compelling argument to go pure.

No comments: