case statements for enumerated types with huge chunks of code for each one scream out "Make me into separate classes".

Comments

  1. Facing that exact challenge these days.

    20+ huge procedures and a large number of support routines in the same class, and a case statement to decide which one to call.
    Not only that, there are also the same case statements for the same enums in several functions, returning short name strings,  long name strings, status messages, etc.

    The challenge with refactoring these are interdependencies where one enum value's code might actually call code that is shared with another enum.  

    Proceeding with caution.

    ReplyDelete
  2. The class, which has tripled in size and number of enums since I started,  is complex.  The code is in continuous flux as we are currently adapting for the needs of a subsidiary, while trying to not break our own needs.  There just isn't a right time to do this - so I doing a template for the new class hierarchy and trying to mature it as far as I can before actually splitting out the code into a class factory.  To make it even more fun, these are queueable tasks which are handed to a worker thread pool, and there is a scheduler/dispatcher that needs to know if tasks can be run in parallell or if they have to be serialized.

    ReplyDelete
  3. If there is one thing to be thankful for: very few "global" properties :)

    ReplyDelete
  4. Sounds like a case for the strategy pattern.

    P.S.: We should rename this group into "Nicks daily code rants" ;)

    ReplyDelete
  5. +1. However that depends on definition of "huge" ;-)

    ReplyDelete

Post a Comment