I am building a project that I might consider to open source. I have a UIView Category that gives me easy accessors for setting x,y coordinates, or width and left directly to a UIView, without dealing with the frame. My question is, should I use such categories in my project if I plan to open source it?
A lot of projects will have a similar category with methods for UIView like
- (void)setLeft:(CGFloat)left;
or
- (void)setX:(CGFloat)x;
And my understand is that if 2 categories create a method, you will have no guarantee about which is going to be called.
So... what should I do? Not use category at all and deal with this annoying code in my open sourced project? Use categories and maybe prefix the method names?
Thank you!
Don't bother adding these methods.
They save very little typing, the prefix you really should add will be ugly, and they add almost no real convenience while making code written against that added API no longer portable to projects that lack it.
As well, having a bunch of convenience methods makes it significantly more difficult to subclass. Which method(s) do you have to override? What is the behavior of KVO? Is there a primitive method that everything is funneled through or do you really have to override everything?
The frameworks generally do not add such convenience API because it creates a lot of extra "weight" to the API while incurring all of the issues mentioned above. All those extra methods are just more data points for the developer to have to learn about, remember, and explain to others when introducing new people to the project.
One exception is the class cluster classes; NSString, NSArray, etc... they have a core set of primitive methods that provide all functionality needed to implement the rest of the APIs. The rest of the methods on the abstract classes are implemented entirely in terms of those primitive methods. When subclassing, you only need to implement the primitives and all other behaviors will "just work". However, subclasses are free to override any of the non-primitives for optimization or customization purposes (though, careful, you really should preserve the behavior).
The general rule of thumb is that if a convenience API doesn't save more than a few lines of code on a regular basis, it isn't worth it.