if else

[Peter]

Hi

I have a property (item.Id) which contains a Guid. Based on the value
of this Guid I have to execute one of several different tasks. The
tasks are really all variations on the theme "obtain user data from a
database", and at the moment these "tasks" are just methods I call in
my class.

What is a nice syntax for this type of requirement? At the moment I
just use a big if-else (like that below), calling the appropriate
method, but I can't help but believe there's some more elegant
structure for this.

IList<UseruserList;
if (item.Id == guid_1)
{
userList = FindUsers_1();
}
else if (item.Id == guid_2)
{
userList = FindUsers_2();
}
else if (item.Id = guid_3)
{
userList = FindUsers_3();
}
else
{
userList = FindUsers_X();
}
Thanks,
Peter

[Marc Gravell]

Maybe a dictionary of Guid to delegate instances (such as Action)?

var actions = new Dictionary<Guid, Action>
{
{guid1, SomeMethod},
{guid2, SomeOtherMethod}
//...
};
Action action;
if (actions.TryGetValue(item.Id, out action))
{
action(); // invoke
}

Obviously you might choose to cache the dictionary somewhere rather than
re-create it each time...

Marc

[Ignacio Machin ( .NET/ C# MVP )]

On Oct 2, 8:20 am, "Peter" <[e-mail]:

Hi

I have a property (item.Id) which contains a Guid. Based on the value
of this Guid I have to execute one of several different tasks. The
tasks are really all variations on the theme "obtain user data from a
database", and at the moment these "tasks" are just methods I call in
my class.

What is a nice syntax for this type of requirement? At the moment I
just use a big if-else (like that below), calling the appropriate
method, but I can't help but believe there's some more elegant
structure for this.

It depend of the way you generate the list.
If the guid are always going to be the same (it seems) and the tasks
are harcoded you can use a switch instead of a number of if/else.
If the task can change you could create a dictionary with a <guid,
ActionDelegatecan work the same.
You still have to fill it though.

[Marc Gravell]

'cos it takes less typing than Dictionary<Guid, Action;-p

Obviously it would work fine either way (in C# 3.0, at least) - but to
my view there is no information lost by using "var" here - it is
immediately obvious (from the declaration/initialization) that the
variable is a Dictionary<Guid, Action>. Note that I wouldn't do this
with "int" etc - but Dictionary<Guid, Actionis a lot of characters
for the eye...

The only time var is strictly /necessary/ is when using anonymous
types - but it has other uses, especially with complex generic
collections - the names get very wordy, without adding anything
(caveat: subjective).

Marc [C# MVP]

[Brian Gideon]

On Oct 3, 7:28*am, Marc Gravell <[e-mail]:

'cos it takes less typing than Dictionary<Guid, Action;-p

Absolutely. And it's not just because we're lazy (although that is a
good reason). I think it enhances readability especially in cases
where it reduces lines that would normally scroll off the end of the
screen down to half their length.

[Jibesh]

One doubt

are we getting any performance improvement from moving to Switch instead of
using If/else ?

implementation of switch statement uses if/else only isn't ?

Thanks
Jibesh
"Ignacio Machin ( .NET/ C# MVP )" <ig************@gmail.comwrote in
message
news:f3**********************************@x35g2000 hsb.googlegroups.com...

On Oct 2, 8:20 am, "Peter" <[e-mail]:

>Hi

I have a property (item.Id) which contains a Guid. Based on the value
of this Guid I have to execute one of several different tasks. The
tasks are really all variations on the theme "obtain user data from a
database", and at the moment these "tasks" are just methods I call in
my class.

What is a nice syntax for this type of requirement? At the moment I
just use a big if-else (like that below), calling the appropriate
method, but I can't help but believe there's some more elegant
structure for this.

It depend of the way you generate the list.
If the guid are always going to be the same (it seems) and the tasks
are harcoded you can use a switch instead of a number of if/else.
If the task can change you could create a dictionary with a <guid,
ActionDelegatecan work the same.
You still have to fill it though.

[Peter Duniho]

On Thu, 02 Oct 2008 18:05:23 -0700, Jibesh <ji*******@gmail.comwrote:

One doubt

are we getting any performance improvement from moving to Switch instead
of
using If/else ?

implementation of switch statement uses if/else only isn't ?

Not necessarily. Depending on the cases, different strategies can be
used. In the best case, a simple jump table can be used, providing much
better efficiency than a sequence of if/else statements.

That said, IMHO the most important part of using a switch statement is to
preserve the semantics of the problem. If what you have is a series of
possibilities that can be encoded in a switch statement, then the switch
should be used. That would be true even if, for some bizarre reason, the
compile switch statement was _slower_ than the if/else statements.

The performance is a consideration that's a distance second to making the
code readable and maintainable. One should only worry that much about it
if and when there's a demonstrable performance problem that needs
resolving.

Pete

[Michael Starberg]

"Brian Gideon" <br*********@yahoo.comwrote in message
news:68**********************************@z66g2000 hsc.googlegroups.com...
On Oct 3, 7:28 am, Marc Gravell <[e-mail]:

'cos it takes less typing than Dictionary<Guid, Action;-p

Absolutely. And it's not just because we're lazy (although that is a
good reason). I think it enhances readability especially in cases
where it reduces lines that would normally scroll off the end of the
screen down to half their length.

Yep yep. Also using the var aligns local variables pretty neatly.
Very good for readability

- Michael Starberg