HomeiDevBlogADayThe Stunning Utility of Global Classes


The Stunning Utility of Global Classes — 5 Comments

  1. In my experience, a common entry point for all application data tends to get unwieldy after awhile.

    For things like application colors, I usually use a UIColor category (imported in prefix.pch), so I can do things like [UIColor myAppColor] wherever. It’s slightly more elegant than [Data myAppColor], in my opinion. Same things goes for fonts.

    For application settings I either use NSUserDefaults or Core Data. The former only if the settings are minimal (which they almost never are).

    If need access to commonly used methods, my answer is almost never “put them on a globally accessible class”. Rather, I like to put them close to objects they belong to, usually on models (fat models, slim controllers!) or categories.

    For instance, let’s say I have a Core Data entity called Preferences (for user preferences). And assume the user can set the background color for the app. I store the color in the Core Data entity and add an instance method to the Preferences class that fetches the color.

    I tend to use singletons for a few things though. Mainly to slim down my application delegate – and only if it really is something that should only be instantiated once. Things like persistent core data variables and a decorator for CLLocationManager, if I need one.

  2. @Jesper – Thanks for your comment. I like the category idea; an elegant alternative! To be clear, regarding global classes, I certainly was not advocating that one should put _everything_ there. If there is data that belongs with a specific class, then by all means, it should go there! But if there is data, or a class of data like settings for example, that one needs to access from different, perhaps unrelated places, then I think a global class (or perhaps even a category) can work well. I do agree that a global class could become bloated over time. So like anything, these are techniques to use carefully.

    In the end, and as usual, there are always many ways to solve these kinds of problems, and personal preference plus experience plays a major part in choosing one.

    Thanks for posting your best practices here. I do appreciate that!

  3. You’re right, a lot of it is a matter of preference. It’s certainly interesting to discuss. And best practices can always be further refined!

    The reason I tend to shy away from globally accessible classes is that they tend to become everything-buckets. (“Where should I put it? It doesn’t fit anywhere. I’ll just stick it in the GlobalData, for now.”) I’d rather rethink the design if it comes to that – if it isn’t a model, maybe it should be.

    I think categories are underestimated, in general. It’s a good way to group related methods, and you can even use instance variables (with the Objective-C runtime).

    And singletons is a whole other can of worms! Though they are unavoidable, at times. 🙂

  4. Oh yes, I do love categories. I did an app that had a substantial data set, derived from JSON via a RESTful API, that was handled simply with NSMutableDictionary. I wrote a category on NSMutableDictionary to provide accessors and such for the data that made writing the rest of the app a breeze and very easy to read and understand. Sounds like another blog post… 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

HTML tags allowed in your comment: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>