Re: Weird calculation
Re: Weird calculation
- Subject: Re: Weird calculation
- From: "Erik M. Buck" <email@hidden>
- Date: Fri, 25 Jan 2002 11:20:53 -0600
>
I'm sorry, I should have been more clear. The code fragment above should
>
have started with switch([[[NSUserDefaults standardUserDefaults]
>
objectForKey:@"someKey"] intValue]). The object returned by the defaults
>
is an NSNumber, and it can contain a value of 0,1, or 2, corresponding
>
to three different user settings. I'm going to have the same object do
If a preference value is stored as a number, there may be no alternative
other than to use a switch statement or if statements to do the right thing
based on the number.
Several options spring to my mind:
1) Store the selector to use in the defaults. NSStringFromSelector() and
NSSelectorFromString().
When loading the preference value, verify the existence of the method
specified by the selector and store the selector in a variable for future
use. Different selectors can produce different behaviors. This is
effectively a use of the "Command" pattern.
2) Store string names for different behavior modes. At least a person hand
editing the preferences plist will guess what to do instead of wondering
what "2" means is a particular context. Using the provided example,
storing "doOneThingByDefault" may be more informative than storing "2".
3) The "State" or "Strategy" patterns may be useful. The value stored in
preferences can be used to select the state or strategy to use. A switch
statement might still be needed to select the state or strategy initially,
but on the other hand, combining option 2 and option 3, the string stored
could be the class name of the state or strategy controlling class.
NSClassFromString() and NSStringFromClass(). e.g. store "MYStrategy1" or
"MYStrategy2" in the defaults.
If you find yourself writing the same switch statement multiple times in
code, you are definitely missing an opportunity to use polymorphism. I
suppose it may be appropriate to use one switch statement to select a class
or selector to use in the future, but using multiple switch statements in
multiple places to make decisions based on a stored value is a bad idea.
Store the value as an object or selector instead.
Finally, it is possible to store any object and any graph of objects in a
plist. The simplest way is to archive the objects into NSData and store the
data. There is not much qualitative difference between storing the number 2
in preferences and storing arbitrary data. There is a quantitative
difference though :( The more complex way is to use the plist format to
encode all object properties. My company has EMBPropertyProtocol.h,
EMBPropertyCodingProtocols.h, EMBPropertyDecoder.h, EMBPropertyCoder.h.
These are similar to NSCoding and NSArchiver and NSUnarchiver except that we
use plist as the storage format. Arbitrary graphs of objects, cycles, etc.
are all stored correctly in a somewhat human readable format. I know other
companies have similar capabilities and some of them have been posted to
this forum and others. Apple has even mentioned that they have such a thing
internally.
>
How could I do this? I'm not just trying to be argumentative - if
>
there's a better way to do this, I'd like to know what it is.