Cocoa ground rules

Since I've seen many people violate two ground rules of object-oriented programming (OOP), I thought I'd list them here, in the hopes it'll help some beginners not fight the frameworks but rather go with the flow in Cocoa.

1. Encapsulation: Every object is supposed to be self-contained and go about its work without needlessly exposing internal details. In particular, you have no business looking at its retain count. Retain counts are there to let several objects share ownership of another object without having to care about their co-users.
   
   So, trying to make sure the retain count of an object hits zero when you're finished is silly because the object may even internally retain and release itself until some important piece of work has been finished, and if you force it to go away, you'll break it.
   
   The advantage of encapsulation in practice is that if you create an object of your own and need to completely change the way it does its work in a later revision, you can simply swap it out for another object that works differently (and may or may not create helper objects that retain it) without the rest of your app needing any changes.
2. Maintainability: When you program, you spend only a fraction of your time writing code, and a lot more of your time reading it. Even while you write code, you are constantly glancing at the code you already wrote. So, write your code so it's easy to read and easy to fix bugs, not so you save a couple minutes typing.
   
   The main tools for making code easy to read are to factor it cleanly (i.e. to make sure functions and methods aren't several pages long), breaking out stuff you use repeatedly into helper functions (your code will then read like while( GetNextObject() ) PrintThisObject(); instead of being hundreds of instructions to sift through), and to not copy code but rather to share code, so that when you fix a bug in the one shared copy it is fixed in the whole program.
   
   Object-oriented programming encourages code reuse. So, don't think "blimey, I have to create another class," but instead think of how much code you'll save writing in the future if you take this particular functionality and extract it into a small, self-contained object.
   
   The self-contained part is a good indicator here, especially if it's an object that can work like a filter, i.e. take input, process it in some way and then give output, it's a good candidate for a class of its own. Like a list of applications: It takes an array from a file (Preferences?), allows modifying this list, saves the list, and of course allows other code to use this list for their own nefarious purposes (like, refuse to run if one of these applications is running).

Reader Comments: (RSS Feed)

Andy Finnell writes: While agree encapsulation/information hiding is really important, I think reusability is often given too much weight. Maintenance is a much more frequent occurrence (why encapsulation is important) and should be given a higher priority when writing code. I ended up writing a short article on code maintenance vs reuse: http://www.losingfight.com/blog/2006/09/03/its-not-about-code-reuse-its-about-maintenance/

Uli Kusterer replies: ★ @Andy: Good point, the reason behind the desire to reuse code is not just laziness, it is maintainability. I'll change the article accordingly. Thanks!

Comment on this article: Name: E-Mail: (not shown, hashed for Gravatar) Web Site URL: (optional) Comment: (plain text only) Please Enter the following word:

Or E-Mail Uli privately.