Because of all the time I spent looking at other people’s code, using other people’s code, and simply writing damn code, it became quite rare for me to find good Objective-C I am not already aware of. Maybe I am not looking the right places, but that’s how it is.
Today, however, I found a new awesome practice that got me super excited and blogging once more.
Restrict and Defend!
When writing code, good code, always restrict and defend!
What I mean by restrict is to disable any behavior that external code might impose on your code in a way you have not meant for it to be. An example will make this crystal clear.
Let’s say you have a singleton class. In most languages that have sane constructors, you can easily declare the constructor as private and you are all set. External code can’t instantiate the singleton, and can only access the shared instance. We can’t do that in objective-c, but here is what we can do:
- (id)init __attribute__((unavailable));
This marks the init method with an unavailable attribute so external classes cannot instantiate an instance. I would take this a step further, and mark the
+[NSObject new] method as unavailable, as well.
I know, Mr. Smarty Pants, the caller can easily work around this using
performSelector: or even casting to
id, but all we have to do, really, is throw an exception in the
init method, and use another
init for our internal use.
Put Up Those Defenses!
As for defending, it is the practice of validating parameters passed to your objects. The simplest defense is
NSParameterAssert, which asserts that the parameter passed is not
nil. You would want to use that when you absolutely need a parameter to be a valid, non-
Other defenses can be set up using
NSAssert by validating strict assumptions you are making about the passed objects.
They say less is more. In our case, less is more and even better.