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: Michael Ash <email@hidden>
- Date: Thu, 26 Feb 2009 10:53:22 -0500
On Thu, Feb 26, 2009 at 9:49 AM, I. Savant <email@hidden> wrote:
> 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.
I think that this is a poor example because you have an enormous
amount of repeated code. I'd write it like this:
- (void)_seek:(BOOL)direction withFactor:(int)factor
{
[mediaController seek:direction withFactor:factor];
[self updateUI];
}
- (IBAction)seekForward:(id)sender
{
[self _seek:YES withFactor:0];
}
- (IBAction)seekForwardFast:(id)sender
{
[self _seek:YES withFactor:1];
}
- (IBAction)seekBackward:(id)sender
{
[self _seek:NO withFactor:0];
}
- (IBAction)seekBackwardFast:(id)sender
{
[self _seek:NO withFactor:1];
}
And when you do that, IMO it becomes obvious that having separate
methods is the best way to go. It's less code, it's clearer, it
requires less IB setup, and won't fail strangely because you forgot a
tag in IB.
It's true that there are scenarios where dispatching off the tags are
helpful, but I don't think that this is one of them. Dispatch is what
the language is good at. You're making choices based on what's calling
you, and the things that are calling you can be configured to call
different methods. It's a no-brainer to me to take advantage of the
language's dispatch ability rather than build your own unless building
your own ends up being significantly better in some way.
Extra methods aren't a hardship. Extra *code* is, but the above is
less code than the case/switch, not more.
Mike
_______________________________________________
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