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 😎



  • @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.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.