You should not create this object (you really shouldn't create this object in C# either, but we're discussing ObjC right now). There is no object-oriented sense to a class that is "all the constants for a program." The correct place to put these values is in the classes that require them. So for instance, if you create a string constant for an NSNotification
name, you should put its definition in the class that posts that notification.
In general, you do not put these kinds of constants inside of classes at all. You use prefix naming for them to indicate what they relate to. So for instance, the UIApplicationDidBecomeActiveNotification
string constant is defined in the UIApplication.h
header file, thus:
UIKIT_EXTERN NSString *const UIApplicationDidBecomeActiveNotification;
UIKIT_EXTERN
is a portability macro that resolves to just extern
. Inside of the .m
, you would have some line like:
NSString *const UIApplicationDidBecomeActiveNotification = @"UIApplicationDidBecomeActiveNotification";
While this constant goes inside of UIApplication.h
, it is not inside of the UIApplication
class, or any class. Objective-C doesn't provide the kind of scoping you're used to in C#. We use naming prefixes instead of namespaces.
The same rules apply for other types; this isn't just for strings. For example, again from UIApplication.h
:
typedef NS_ENUM(NSInteger, UIApplicationState) {
UIApplicationStateActive,
UIApplicationStateInactive,
UIApplicationStateBackground
} NS_ENUM_AVAILABLE_IOS(4_0);
Here we define an enum, which indirectly is defining various integer values. Again, this is just in the header file. There is no encapsulation inside of UIApplication
. We only know that it's part of UIApplication
because of its prefix.
Even those things that are ubiquitous through the whole system, such as UIKitDefines.h
and Availability.h
, are still broken out into their own contained headers. There is no "here are all the definitions for all UIKit objects" file. You shouldn't create one for your program either.
Note that this use of global variables is only appropriate for constants. You should not use globals this way for mutable variables. They should belong to some class and have accessors. But again, they would belong to the class that uses them, not a "generic program stuff" class.
See also @Benedict Cohen's answer for how to implement these things as class methods, which has some benefits (it permits subclassing, for instance). It is also somewhat less convenient, and is not the most common approach.