Re: Weird calculation
Re: Weird calculation
- Subject: Re: Weird calculation
- From: "Erik M. Buck" <email@hidden>
- Date: Thu, 24 Jan 2002 14:21:30 -0600
I did not say never use switch statements. I said "almost certainly doing
something wrong" in Objective-C. Polymorphism exists in large part to
eliminate the fragile coupling that results from switch statements. In the
example to which I was referring, the switch statement was a prime example
of unwarranted fragile coupling between a user interface element that is
readily changed and hard coded indices into the list of elements in that
user interface element. If the user interface element is changes in any
way, the hard coded switch statement would break. I suggested using
Objective-C messaging to avoid the whole problem and be less couples and
more flexible with fewer lines of code. (all good things).
>
>
You should never use switch statements? What's the correct way to do
>
something like this, then:
I dis not say that.
>
>
int answer = NSRunAlertPanel(@"header",@"question",@"button 1",@"button
>
2",@"button 3");
This is a rare bit or procudural style API in Cocoa. A switch statement can
be used or just if/else if since there are only three possible return
values. The possible return values are not subject to independednt change
the way a pop-up menu in IB is subject. Unless Apple changes
NSRunAlertPanel's return values your code will not break. Using a switch
stemenent in this case is still tight coupling be it least it is coupling
with a small amount of data that is not easy or likely to change.
>
>
switch(answer)
>
{
>
case NSAlertDefaultReturn: // user pressed button 1
>
[self doWhateverTheDefaultButtonIsSupposedToDo];
>
break;
>
case NSAlertAlternateReturn: // user pressed button 2
>
[self doWhateverTheAlternateButtonIsSupposedToDo];
>
break;
>
case NSAlertOtherReturn: // user pressed button 3
>
[self doWhateverTheOtherButtonIsSupposedToDo];
>
break;
>
}
>
>
Also, how should one do this:
>
>
switch([[NSUserDefaults standardUserDefaults] objectForKey:@"someKey"])
>
{
>
enum someSetOfPreferences {
>
doOneThingByDefault;
>
doAnotherThingByDefault;
>
askUserEachTime;
>
}
I would say that the object obtained from [[NSUserDefaults
standardUserDefaults] objectForKey:@"someKey"] houlkd have a method
called -doSomething. Use polymorphism to obtain the different behaviors
depending on the particular object obtained. Various design patterns can be
used to add even more flexibility and reduce coupling even more. The code
that you suggest below is very fragile. If another option is ever added to
the defaults then the code will break.
However, I am not the sole provider of programming wisdom. Do whatever you
want and live with the consequences. It is your life and your maintence
hassle. I personally think that loosest possible coupling combined with
fewer lines of code is a win-win situation. If you are using a switch
statement, you are "probably" not achiveing loose coupling or fewer lines of
code.
>
>
case doOneThingByDefault:
>
// do the thing
>
break;
>
case doAnotherThingByDefault:
>
// do things according to this setting
>
break;
>
case askUserEachTime:
>
// ask the user and do what he/she says
>
break;
>
}
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.