Create classes to represent your model objects

« previous entry | next entry »
Dec. 18th, 2006 | 11:39 pm

Collections are quite widely used in a lot of the code I see posted to the Cocoa-dev mailing list and elsewhere. Unfortunately, many times they're not used to represent collections of objects but rather to represent objects themselves. In one recent pathological case, I even saw some code that used an NSMutableArray as a model object instead of the typical NSMutableDictionary, complete with hard-coded indexes to represent the different properties of the object!

Why's this a problem? This goes back to the core tenet of object-oriented programming: In object-oriented programming, you write software by sending messages to objects, and these objects are state plus behavior. When you use a dictionary or an array as a model object behavior goes out the window — the only behavior you'll get out of that model object is that which makes it a dictionary or array, not anything specific to your application.

Thus even if you're only just going to implement accessors to start with, you're generally better off creating classes to stand behind your model objects because you'll have an easier time moving appropriate behavior into them. And if your application targets Leopard this is extra-easy thanks to the new support in Objective-C 2.0 for properties.
Tags: , , , , , ,

Link | Leave a comment | Add to Memories | Tell a Friend

Comments {8}

Fraser Speirs

(no subject)

from: [info]fraserspeirs
date: Dec. 19th, 2006 11:45 am (UTC)
Link

Thus even if you're only just going to implement accessors to start with, you're generally better off creating classes to stand behind your model objects because you'll have an easier time moving appropriate behavior into them.

Agreed. The other major benefit I've found is that it makes the code that operates on these models much more readable and maintainable. A call to named (and, importantly, well-named) accessors is much more readable than code accessing collections.

Also, for developers still targeting Tiger and earlier, it's worth mentioning Accesorizer.

Reply | Thread

Great post + a request

from: anonymous
date: Dec. 19th, 2006 02:53 pm (UTC)
Link

This is great stuff.

Unrelated -- I request that you switch to something other than LiveJournal, and I'll do my best to make sure everyone finds you. The commenting system and a number of other things feel more natural on Blogger and other services. For example, I can't sign the post unless I'm a LiveJournal/OpenID user.

Scott Stevenson

Reply | Thread

Chris Hanson

Re: Great post + a request

from: [info]chanson
date: Dec. 24th, 2006 04:39 pm (UTC)
Link

Thanks, Scott!

I actually really like LiveJournal. (LiveJournal: It's not just for emo teens! It's also for, uh, emo thirtysomethings...) I know that the lack of support for anything but LiveJournal/OpenID for signing posts is a hassle — hopefully they'll have a third "name and URL" option someday soon — but I actually find most other things about LiveJournal very natural. In particular, I really like the tagging system, the access-control features, and the fact that I've had only the tiniest bit of comment spam over the nearly 5 years that I've been using LJ.

If I were to have separate "personal" and "professional" blogs I'd probably keep this for my personal and set up another site using another service for my professional blog. On the other hand, I'd definitely want to use an engine that was at least comparable to LJ in its feature set (except perhaps on the access-control front), which can actually be a little tough to find.

Reply | Parent | Thread

(no subject)

from: anonymous
date: Dec. 19th, 2006 05:18 pm (UTC)
Link

I've always thought creating the data model is the most "fun" part of building an application. Putting together objects based on nothing other than an idea of data and how it interacts lets you be a lot more creative than working with strict database or API rules.

Reply | Thread

Great thought, and I linked back a response...

from: anonymous
date: Dec. 24th, 2006 09:19 am (UTC)
Link

But, uh, I agree with Scott, LJ really does suck.

Reply | Thread

Collections widely used within Cocoa too

from: anonymous
date: Dec. 29th, 2006 12:08 am (UTC)
Link

Before coming to Cocoa, most of my prior OO experience was with Java. So I was surprised to see how much the Cocoa API uses the collection classes internally, especially NSDictionary, which pops up everywhere -- getting process info, getting file attributes, inspecting/configuring attributed strings, etc., etc., etc. In the Java world the dictionary values would be recast as getters/setters on some non-collection object.

At first that bugged me, but I've come to appreciate seeing objects and data structures as distinct things. It also helps mitigate the problem of classes communicating without exposing too much of their own inner workings (http://www.cocoadev.com/index.pl?GettersAndSettersAreEvil). Someone in the linked discussion pointed out an interesting quote along these lines:

I particularly dislike classes with a lot of get and set functions. That is often an indication that it shouldn't have been a class in the first place. It's just a data structure. And if it really is a data structure, make it a data structure. (Bjarne Stroustrup)


So while overuse of collections can be a bad thing, the other extreme can also get out of hand. I'm a big fan of the middle path.

Scott

Reply | Thread

Now not a fan of LJ either

from: anonymous
date: Dec. 29th, 2006 12:11 am (UTC)
Link

Funny, it said that 'a' was a valid tag, and it previewed fine, but then it posted all funny. What's the secret to adding a link in LJ?

Scott

Reply | Parent | Thread

Chris Hanson

Re: Now not a fan of LJ either

from: [info]chanson
date: Dec. 29th, 2006 12:23 am (UTC)
Link

I think this may be a glitch in the particular template I'm using. Your comment came through email to me as an "a" tag with a valid URL, but has been broken out into a boldfaced section followed by a textual (non-link) URL in parentheses. This may be an anti-spam measure.

Reply | Parent | Thread