0

i am using enums as alternative for 250+ cases inside switch.

 switch(variable){
  case "NAME":
  case "MIDDLE":
  case "LAST":
    return a();
    break;

  case "SUFFIX":
  case "PREFIX":
     return b();
     break;
   }

I have problem in handling the above situation while using enum.

public enum Action { 
NAME {
@Override
 public String getVariableData() {
  return a();
 }
},LAST {
@Override
public String getVariableData() {
  return a();
 }
},MIDDLE {
@Override
  public String getVariableData() {
     return a();
 }
},SUFFIX {
@Override
 public String getVariableData() {
     return b();
  }
},PREFIX {
@Override
  public String getVariableData() {
     return b();
  }
 };

 public abstract String getVariableData();
 }

Here NAME,MIDDLE,LAST returns same value. But my question is why i need to implement saperately and how to reuse the existing implementation. Please Help me to reduce the code my reusing the existing implementations.

  • Why do you want to leave first oslution ? – azro May 26 '20 at 09:07
  • That probably says that your attempted improvement is actually not achieving the goal. So, maybe you should ask a question on the original problem in its own context. – ernest_k May 26 '20 at 09:07
  • You cannot reuse that code, each enum value must implement abstract method. – FilipRistic May 26 '20 at 09:15
  • ernest_k please refer https://stackoverflow.com/questions/61243218/reduce-the-number-of-non-empty-switch-cases-sonar-lint-issue above link for my original problem..thats the reason why i changed from switch to enums – Srikanth Reddy Kallem May 26 '20 at 09:48
  • azro there are around 250 cases like that. It is getting readability issue. You can refer to my original problem(link provided above) so that you will get your answer – Srikanth Reddy Kallem May 26 '20 at 10:16

1 Answers1

0

I suppose, you can create a set of interfaces and implementations like a strategy pattern https://www.baeldung.com/java-strategy-pattern:

interface Action {
    String getVariableData();
}

interface ActionA extends Action {
    default String getVariableData() {
        return "a";
    }
}

interface ActionB extends Action {
    default String getVariableData() {
        return "b";
    }
}

enum ActionAImpl implements ActionA {
    NAME, MIDDLE, LAST
}

enum ActionBImpl implements ActionB {
    SUFFIX, PREFIX
}


public static String doAction(Action a) {
   return a.getVariableData();
}

public static void main(String[] args) {
     System.out.println(doAction(NAME));
     System.out.println(doAction(SUFFIX));
}

Or it can be done with Map of Actions like:

public static String process (ActionCode code){
    return actions.get(code).getVariableData();
}


Map<ActionCode, Action> actions = new HashMap<>();
actions.put(ActionCode.NAME, DefaultActions::getDefaultVariableData1);
actions.put(ActionCode.MIDDLE, DefaultActions::getDefaultVariableData2);
actions.put(ActionCode.LAST, () -> "custom info");

enum ActionCode {
    NAME, MIDDLE, LAST, ...
}

interface Action {
    String getVariableData();
}

final class DefaultActions {
    static String getDefaultVariableData1() {
        return "a";
    }

    static String getDefaultVariableData2() {
        return "b";
    }
}  
  • Actually there are around 250+ variables. Based on variable Id it should call particular method and get that value. If i create and interface and class for each and every variable then code will get messed up right? And also i need to mention that every function will return string by the executing different queries. Its not just simple string return. It performs db operation and gets that variable data from database. – Srikanth Reddy Kallem May 26 '20 at 09:51
  • And all 250+ variables return different results? Or unique results number is less then variables? If there are 250+ diferent results, your approach with enum can't be simplified, as you need to connect each variable with result – Alexander Terekhov May 26 '20 at 09:53
  • 80% of the variables have different logics which results in different results and 20% are same – Srikanth Reddy Kallem May 26 '20 at 09:57
  • You can refer my actual problem here: https://stackoverflow.com/questions/61243218/reduce-the-number-of-non-empty-switch-cases-sonar-lint-issue – Srikanth Reddy Kallem May 26 '20 at 09:58
  • Ok, then you can mix this approach with strategy. You can have enums with similar values implementing interface with default logic, and others as you did in your example. – Alexander Terekhov May 26 '20 at 10:01
  • Is it best practice to mix like that? I want to maintain readability, reusability and maintenance of the code should be easy. – Srikanth Reddy Kallem May 26 '20 at 10:05
  • I think, it's ok to extract some default behaviour. The main problem of readability and etc. is 250+ different results. I would consider a possibility to refactor it to reduce results as possible. – Alexander Terekhov May 26 '20 at 10:08
  • Actually there are 300+ different results but i reduced it to around 250 by doing some refactoring. Cant reduce them anymore. I think i should accept this is the only way and proceed. Readability is the factor which is getting effected by this i think – Srikanth Reddy Kallem May 26 '20 at 10:11
  • I suppose, it alo can be done by `Map`. Readability will be +- the same – Alexander Terekhov May 26 '20 at 10:55
  • Can you provide any sample code for Map? – Srikanth Reddy Kallem May 26 '20 at 14:25
  • Edited my answer – Alexander Terekhov May 26 '20 at 14:50