Re: Global variable for whole application.
Re: Global variable for whole application.
- Subject: Re: Global variable for whole application.
- From: Brian Willoughby <email@hidden>
- Date: Thu, 19 Apr 2007 16:54:48 -0700
Don't forget that you can subclass NSApplication and tell IB and
Xcode to use your subclass instead of the generic class. You can
access application-global information through NSApp, a global
variable present in all AppKit programs. Sometimes I wrap user
defaults in application methods so that I can enforce behaviors.
Overall, this is great for code which is specific to one application
rather than just a group of classes. You can even reuse the
NSApplication for future programs if you write things generically
enough. Before NSDocument was created, I put much of its
functionality in an NSApplication subclass that I used as a basis for
every program I wrote. These days it's less necessary, but still
helpful for enforcing global behavior.
Uli's approach is also good, and would be necessary for a library of
code that might be reused in more than one application. Without
multiple inheritance, it would be unwieldy for every framework to
subclass or categorize NSApplication, so it is better in those cases
to use a singleton.
Lots of object-oriented design pattern options for implementing globals!
Brian Willoughby
Sound Consulting
On Apr 19, 2007, at 02:04, Uli Kusterer wrote:
Am 19.04.2007 um 06:41 schrieb Tony S. Wu:
my approach is to create a class that handles global variables.
Me too, I usually have some singleton that contains the code that
accesses the global, so I just make the "global" an instance
variable of that singleton.
To store the singletons themselves, I generally use file-static
globals in the implementation file, or static variables in a
function, and write an accessor function a la [NSUserDefaults
sharedUserDefaults]. That way I avoid name collisions with other
classes, and prevent spaghetti code because someone directly
changes my global instead of going through my class.
For notification names and other strings that need to be pointer-
comparable, I use regular globals in implementation files (const,
if using a C version that lets me do that), plus extern
declarations in the class header. That runs the risk of name
collisions, but since they need to be externally accessible, that's
a given anyway, and generally the linker will catch the duplicate
declaration.
For integer constants, bit flags, four-char-codes and character
constants, I usually use enums. enums have the advantage that they
can be named and used as a type and can thus be used to ensure
nobody passes the wrong constant to my function. Not to mention
they serve as self-documenting code because nobody has to look up
in the documentation what valid values are, and the compiler even
catches wrong uses. And even if I have to allow other values, I can
at least refer to the enum by name to tell people where to find the
special values.
For floating point constants, C-string constants and almost
anything else, I use #defines if there's no better alternative.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden