2 switch or not 2 switch?
-
hi, i read sometimes that it is "better" to use polymorphy and
reflection instead of switch statements. my question is: does it really
make sense to absolutely avoid switch statements? where would you draw
the line between the abstraction making sense and beeing overblown?
thx,
doser.
-
Well, you'd draw the line if you were using Perl, for example. Perl doesn't have a switch statement. :)
-
@doser said:
hi, i read sometimes that it is "better" to use polymorphy and
reflection instead of switch statements. my question is: does it really
make sense to absolutely avoid switch statements?
A switch statement is usually a good indicator that you should be using polymorphism, but not always. If you find yourself making multiple of
switch blocks on the same value, then you should probably refactor into
a polymorphic class.
Reflection doesn't really factor into the equation.
@doser said:where would you draw
the line between the abstraction making sense and beeing overblown?
The answer to this question always depends on specifics. It's
usually easy to tell if you have too much or too little abstraction,
but you need a big-picture view to do so.
-
ok my example would be:
asp.net related:
page1.aspx has an option where the user can choose a datatype which is
then generated as a database field. this is given among other values to
page2.aspx which creates the result.
now on page2 you have 2 choices:
checking with switch statements which type the user has chosen or going
back to page1 and create an object which "knows" what to do if
(simplified here) i.e. the display() method of the data is
called. on page2.aspx you would just call display() on the object. but:
to do that you need to know how to cast the object - which class was
the one used to instatiate it - right? (cause page2.aspx only recieves
either a request-parameter or a session variable not knowing what type
it is.) this is usually done with reflection.
but somehow this feels a little overblown - maybe i'm wrong ?
-
First of all, I wouldn't use session variables. If your user
bookmarks the display page and comes back later, it'll blow up.
Arbitrary limitations suck, and you have such a simple alternative.
@doser said:
now on page2 you have 2 choices:
checking with switch statements which type the user has chosen or going
back to page1 and create an object which "knows" what to do if
(simplified here) i.e. the display() method of the data is
called. on page2.aspx you would just call display() on the object. but:
to do that you need to know how to cast the object - which class was
the one used to instatiate it - right? (cause page2.aspx only recieves
either a request-parameter or a session variable not knowing what type
it is.) this is usually done with reflection.
I probably wouldn't create a
separate object unless I were reasonably certain the object would be
reused elsewhere. If your display is just a one-off, I suggest
delegating the two display functions to different methods decided by a
conditional. But if you intend to reuse this display method
elsewhere, by all means stuff it in an object.
-
Ok good point. Thx :)
-
@Chris F said:
First of all, I wouldn't use session variables. If your user
bookmarks the display page and comes back later, it'll blow up.
Arbitrary limitations suck, and you have such a simple alternative.
which alternative would that be? page context?
-
@doser said:
@Chris F said:
First of all, I wouldn't use session variables. If your user
bookmarks the display page and comes back later, it'll blow up.
Arbitrary limitations suck, and you have such a simple alternative.
which alternative would that be? page context?
That also wouldn't be available if a user comes back to the page.
Try to stick with passing the values in the query string. Your
real state should be in the DB =).
-
@Chris F said:
That also wouldn't be available if a user comes back to the page.
Try to stick with passing the values in the query string. Your
real state should be in the DB =).
Okay what about that problem:
U have a form on page1.aspx which needs info from page2.aspx.
You go onto that page make ur choice and come back to page1.aspx.
(was a requirement by the customer)
What u don't want is to reenter the values into the form fields of page1.aspx
. So with the querystring-method you would have to pass a big bunch of values
to page2.aspx which doesn't need a single one of them. Then you would
have to pass it back to page1.aspx along with the one value you chose on
page2.aspx. This wouldn't be very efficient coding, right?
-
@doser said:
Okay what about that problem:
U have a form on page1.aspx which needs info from page2.aspx.
You go onto that page make ur choice and come back to page1.aspx.
(was a requirement by the customer)
What u don't want is to reenter the values into the form fields of page1.aspx
. So with the querystring-method you would have to pass a big bunch of values
to page2.aspx which doesn't need a single one of them. Then you would
have to pass it back to page1.aspx along with the one value you chose on
page2.aspx. This wouldn't be very efficient coding, right?
Depending on the kind of information you're passing, you have a few
options. If it's specified that there is no purpose in keeping
the information around beyond a session, then cookies are a good
choice. But if this information sticks around beyond a single
session, you'll want to keep it in the DB. If your info is in the
DB, you only pass the key of the information via the query string.
It's hard to give general advice though, because every application is
different. The above is only meant as a guideline, not a rule.
-
Ok I thank you guys for help. I now have a few things to chew on 8)
-
@Chris F said:
Depending on the kind of information you're passing, you have a few
options. If it's specified that there is no purpose in keeping
the information around beyond a session, then cookies are a good
choice. But if this information sticks around beyond a single
session, you'll want to keep it in the DB. If your info is in the
DB, you only pass the key of the information via the query string.
Interesting. You advised not keeping data in session state because it
won't be there when the user returns later. Wouldn't the same problem
exist if using session (non-persistent) cookies?
I would rather keep that data on the server (where it's needed) and not pump it across the wire to the client.
-
@John Smallberries said:
@Chris F said:
Depending on the kind of information you're passing, you have a few
options. If it's specified that there is no purpose in keeping
the information around beyond a session, then cookies are a good
choice. But if this information sticks around beyond a single
session, you'll want to keep it in the DB. If your info is in the
DB, you only pass the key of the information via the query string.
Interesting. You advised not keeping data in session state because it
won't be there when the user returns later. Wouldn't the same problem
exist if using session (non-persistent) cookies?
Indeed they would. I recommend keeping the absolute minimum state
on the client. In most cases all I store is the authentication
hash. I can't really think of a single time I've had to store
something other than this that wasn't caused by a misdesign.