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.</li>

  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).</li> </ol>

    If you look at Cocoa itself, a lot of its classes are split in a way that they perfectly encapsulate or allow reuse of their functionality. So, the best way to learn OOP is to emulate the way your framework does objects and classes.