Bad smell in code # 10 Select-case Statment and solution on deal with them

 

One of the most obvious symptoms of object-oriented code is comparative lack of  Select Case (switch in C#)  statement. the problem with  Select-Case statement is essentially that of duplication. If-then-elseif-else statement is worse! Often you find the same select case statement scattered about a program in different places.

When you added a new clause to one of the select-case statements,  you probably need to add the similar clause to a  few other select-case statement.  it is commonly understanding that logical switch is the main contributor of Cyclomatic Complexity .  it makes the code base buggy and difficult to test.

 

let’s take a look at how  is the situation in our code base.

 

in Client and Server solution combine, we have about 2100 “Select case” and about  61,500 if statements . Among them, more than half of “Select case” are in UI project, and more than 40%  of “if” statements are in in UI. ( from the fact there about a half of the “logical switch” are in UI, we could tell there could be some good amount of duplications)

 

base on the code metrics recorded in May 28^th this year, we have total of 715,704 LOC in these 2 solutions.  it means we have one if statement or Select case statement in every 11 lines of code in these 2 solutions.  and the code in these solutions makes up 88% of total LOC in 4 major solutions .

 

Let’s look at the solution on how  to deodorize this type of bad smell the code.  Thanks to the object-oriented programming language concept. All object-oriented programming languages ( VB.Net is one of them)  offer polymorphism, which gives us an elegant way to deal with the problem.

 

Most times you see a select-case statement you should consider polymorphism, because these are where  polymorphism should occur.  Often the” select case” switches on a type code, (TransactionType, LicenseType,CustomerType etc.)

 

the following are the stratgeies deal with this type of problem

 

<![if !supportLists]>1)  <![endif]>replace the Type Code with subclass or replace the type code with a state object

 

For Example, supposed we have a class with the name of Employee, and it has a property named Type, based the value of Type property, we get to know if the employee is a salesman or an engineer. what we can do is to make the original Employee class as a base class, and create 2 sub classes for it, one is Engineer and another is Salesman.

Here you are the  example for using State object.  supposedly  in the life of an employee object, the type could be changed back and forth.  in that case, you cannot use sub-class strategy, what you could do is to define a class call EmployeeType and create sub class for Employee Type named Engineer and Salesman.    

 

<![if !supportLists]>2)  <![endif]>replace conditional logic with Polymorphism (override the base class method in sub class with differnet implementation)

 

 

sure, enough, you will have some more classes in your codebase, but believe me,  that’s worth.  these sub classes will grow big enough to justify their own existence as time goes by.  At the same time,  the  occurrence of  “select-case” statement will be less and less.  As one of the direct result of it, the Cyclomatic Complexity  of your codebase will go down.   When that happens, you will see smiling in programmer’s face, and client’s face and of  course, the project manager smiles too.