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!
Access Denied
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-nil value.
Other defenses can be set up using NSAssert by validating strict assumptions you are making about the passed objects.
Conclusion
They say less is more. In our case, less is more and even better.