#pragma mark — Categories
Living inside an UIKit world isn’t as easy at it seems. Wrong decisions may lead you to build sand castles. Today we will try to walk you through this feature (borrowed from SmallTalk) called Categories.
If you surf the web, everybody seems to be dazzled and point out a bunch of advantages:
- Split a huge class into small files.
- Add functionality to a class you don’t have access.
- Add a cross functional feature along an app.
- Feel cool about using them.
All of the above seem to be great use cases, at least theoretically. Even the last one might be true, and at the end of the day you will be at the office, smiling, thinking how great they are and how much you love them.
However, if there is something I have learned during these 3 years is that winter’s coming. No matter how much you love the platform, there is always a “but” and Categories are not the exception to the rule.
Categories lie
A famous doctor once said that everybody lies. He was right and categories do it too. What you see is not what you get, because at the end of the day when everything is said (and compiled) methods in categories just group everything together in one huge class at runtime.
To quickly understand how they work you can picture Esquilax.
A horse, with a head of a rabbit and … a body of a rabbit. Categories claim to be the horse. They will split your code properly, your classes will be lighter and just when you think you are done, Mr.Runtime will come along and do his thing. They just can’t do that.
As I see it, in most cases they are just some fancier way to use #pragmas. In addition, they are a great place to break the Single Responsibility Principle (SRP). Classes should be conceived to do one task. They are not meant to be some kind of Batman’s belt. They should only be willing to change for one reason.
Going SRP effectively is pretty much one of the few challenges iOS development proposes you (besides Cocoa itself). It sets the line between “Oh he’s just a developer I met once” and “I wish he was in my team”.
Categories inside an UIKit world
In a world where UIViewControllers are commonplace we have to take special care when using categories. If not, you might be tempted to do something like this:
Putting coding style to the side, the category above violates the SRP. UIViewControllers are supposed to control views, not phone logic. It’s name is telling you that. This code will be appended to UIViewController class and skipping the import will not make it disappear.
It’s seems really hard to find a perfect suit for categories within UIViewControllers, but if we just limit to what they are supposed to control there are useful implementations. For example:
The example above is effective. It’s name reflects what it’s created for and it a typical piece of code that you would add to a UIViewController. In 15 lines we have designed a great way to disable user interaction within a root view owned by a UIViewController instance.
I am sure you have plenty of examples where it might be a perfect fit for you, but before doing it you should ask yourself:
- Is there another way to implement it?
- Does every instance of this class need this functionality?
- Is it essential for the class purpose?
These questions should be enough to clear your mind and at least be conscious of what you are doing, but you should try it to get your own conclusions.
So don’t get influenced by the cool guys. Don’t use them because it just looks nice. Software developing is all about using the right tool at the right moment. It’s all about making mistakes and learn how to avoid them in the future.
If you like what you’re reading, and would like to work with us write to jobs at Monits dot com with subject “Medium — Job opportunity”.
