Geek asks and answers

Is there a lack of many objective-c categories?

We have code in objective-c categories that we want to share between projects. There are (at least) two approaches that we can take:

  • Put them in one category for each class, naming something like UIView+SGBExtensions
  • Then put in several different categories, using, for example. UIView+SGBLayout, UIView+SGBDrawingetc.

My instinct is to go with the latter, as it will be more visual, and we can make the cherry pick. However, most of our applications will include most of the common code, so I'm a little worried that having a large number of categories can affect the performance or size of the application. Is there a lack of many objective-c categories?

+3
source share
2 answers

I think the difference will be negligible. At boot time, it may take more steps to repeat by category and add their methods, rather than adding methods from the same category. Similarly, if categories have methods +load, these are several method calls, not one. As I said, it’s insignificant.

+3
source

My instinct is the same as yours. Dividing code into your path is more convenient.

I don’t think you should worry about size and performance until your application has a problem with this. Even then, do not suppose to measure. For what it's worth, I'm sure that the impact of performance and size will be close to zero.

+2
source

More articles:


All Articles