Re: One IBAction, multiple results from multiple methods
Re: One IBAction, multiple results from multiple methods
- Subject: Re: One IBAction, multiple results from multiple methods
- From: "I. Savant" <email@hidden>
- Date: Thu, 26 Feb 2009 09:49:57 -0500
On Thu, Feb 26, 2009 at 4:39 AM, Klaus Backert
<email@hidden> wrote:
> ... and now we went from a plethora of methods to the same plethora of case
> statements plus tags.
>
> For the methods the dispatch is made under the hood. The switch statement is
> kind of re-inventing the objected-oriented wheel in a procedural way.
So, after being messaged off-list about this, I can see my simple
example doesn't illustrate things clearly enough. I'm happy to spell
it out.
Consider the example I gave:
>> - (IBAction)seek:(id)sender
>> {
>> int tag = [sender tag]; // or NSInteger tag = [sender tag];
>> switch (case)
>> {
>> case 1001: // seek back
>> [self seekBack];
>> break;
>>
>> case 1002: // seek back FAST
>> [self seekBackFast];
>> break;
>>
>> case 1003: // seek forward
>> [self seekForward];
>> break;
>>
>> case 1004: // seek forward FAST
>> [self seekForwardFast];
>> break;
>>
>> default:
>> NSBeep(); // don't know what to do here ...
>> break;
>>
>> }
>> }
>>
The benefits of this approach over individual actions are zero -
they're about equal (arguments of style ASIDE, please). Now consider a
more realistic one ... same scenario:
- (IBAction)seek:(id)sender
{
// We have to figure out speed and direction
BOOL forward;
int factor;
// The sender (based on its tag) tells us this ...
int tag = [sender tag]; // or NSInteger tag = [sender tag];
switch (case)
{
case 1001: // seek back
forward = NO;
factor = 1;
break;
case 1002: // seek back FAST
forward = NO;
factor = 2;
break;
case 1003: // seek forward
forward = YES;
factor = 1;
break;
case 1004: // seek forward FAST
forward = YES;
factor = 2;
break;
default:
forward = YES;
factor = 1;
break;
}
// Now tell the media controller what to do
[mediaController seek:forward withFactor:factor];
// Maybe update the UI
[self updateUI];
// Maybe do some more complicated things with other arguments ...
}
Now we have the ability to wire up not only four seek buttons, but
four seek menu items (complete with keyboard shortcuts) which all do
exactly the same thing - maybe even perform an additional (or
different) action depending on whether it's a menu item or a button.
They determine necessary arguments and call the necessary method in
one place.
Contrast with this:
- (IBAction)seekForward:(id)sender
{
[mediaController seek:YES withFactor:0];
[self updateUI];
}
- (IBAction)seekForwardFast:(id)sender
{
[mediaController seek:YES withFactor:1];
[self updateUI];
}
- (IBAction)seekBackward:(id)sender
{
[mediaController seek:NO withFactor:0];
[self updateUI];
}
- (IBAction)seekBackwardFast:(id)sender
{
[mediaController seek:NO withFactor:1];
[self updateUI];
}
When you consider this example, the problem the approach solves
becomes clearer (and more beneficial). Of course it's still
questionable whether there's any advantage because this is still a
very simple example. Consider something significantly more complicated
... more seek speeds, more arguments to figure out, different affects
to apply to the UI depending on which control initiated the -seek:
action, etc. Suddenly the idea of having more action methods is less
attractive.
Consider also an NSMatrix of button cells. Or an NSForm. Or lots of
other scenarios where you might have a number of similar controls that
all do the same thing with slight differences. This is one of the big
reasons tags exist in the first place.
In other words, in the simplest cases, it's a matter of style (and I
won't be dragged into that argument), in the most complex cases, it's
the only sane approach. There's nothing wrong it and you're not
"reinventing" anything.
--
I.S.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please 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