Java Best Practices – Is It Good to Burn Business Logic into Enums?

business-logicenumjava

Let's have a simplified business logic like this:

public enum BusinessLogic {
   STAGE_ONE(true, false, false),
   STAGE_TWO(true, true, false),
   STAGE_THREE(false, false, true);

  private final Boolean canStartProcessing; 
  private final Boolean canDoStuff; 
  private final Boolean canFinish;

  private BusinessLogic(Boolean canStartProcessing, Boolean canDoStuff, Boolean canFinish){
     ... usual simple constructor
  }
  ... getters
}

And let's say it is mapped to my Business Object like this:

public class BusinessObject {
  ... constructors, fields, getters, setters, etc...

  private BusinessLogic logic

  @Enumerated(EnumType.STRING)
  @Column(name = "LOGIC")
  public BusinessLogic getLogic(){...usual getter...} 

  public BusinessLogic setLogic(){...usual setter...}
}

When the workflow arrives for example Stage two, the BusinessObject will be updated and LOGIC field should be set to BusinessLogic.STAGE_TWO, therefore you can use functions like "start process" and "do stuff", before that you can't "do stuff", altough when it reached stage three, you can't do anything else, but "finish" the process.

Does this kind of business logic structure has something to do against good practice?
I mean for example: maintainability, not fully represented in Database or anything else I didn't think of?

Best Answer

I use enums this way all the time. Enums are a great way to write immutable helper objects that you only need exactly one copy of; they help reduce the chance of memory leaks and easily group many related classes together in a clear way.

What I would not do is expose the control of which particular BusinessLogic you're using to external classes using a public getter and setter method; that is violating encapsulation.

It looks like your use case uses the State Pattern, which is a great use for enums in Java. However, by removing the state transition logic from the class, you can't guarantee that other code will change the state when you don't expect. Fix this by having the state transition code inside the BusinessObject class itself, or at least in a package private object that you inject into the BusinessObject class.

Related Solutions

Business Logic – Business Rules, Business Logic, Input Validation

You are on the right track. Domain or business validation logic should do more than just report true or false. You want to enable the "user" of your business classes (ie the UI, or your logging system) to do something more than just report to the end-user that something is wrong.

Now, how you do that is completely up to you.

Decision to make: check everything and then report all errors/warnings/information, or stop at the first one you encounter. I would personally opt for the first one and let the UI decide how to use the info. There is a trade-off though: some validations may take longer than others and you may want to check these only if the "simple" ones succeed.

I wouldn't in any case use exceptions to do this. Some people use exceptions because most development environments have a nice way of showing any unhandled exceptions to the user. I think that is just a bad/lazy choice. And not just because it is then hard to decide where the error came from (though stack traces can help there), but also because it can(will) leave your app in an unpredictable state and may cause errors further down the line that will be even harder to debug.

Therefore, I tend to reserve exceptions for, well exceptional, circumstances. Things I didn't foresee. Validation doesn't fall into that category in my opinion - you did foresee all (current) validation concerns or you wouldn't have validated against them.

All in all, I code the validation in the domain/business classes to collect an array (or whatever I care to use) of error/warning/hint instances. They may be simple strings, they can be fully fledged classes. Usually I always return an instance to the caller and never an unassigned pointer. "Valid" is simplu indicated by a message count of zero.

Java Enums – Is switch(this) an Antipattern?

The other alternative is overriding methods per instance:

public enum A {
  A1{
    @Override public boolean isFirstParam(){ return true; }
    @Override public boolean isSecondParam(){ return true; }
    @Override public boolean isThirdParam(){ return false; }
  },
  A2{
    @Override public boolean isFirstParam(){ return true; }
    @Override public boolean isSecondParam(){ return false; }
    @Override public boolean isThirdParam(){ return false; }
  },
  A3{
    @Override public boolean isFirstParam(){ return false; }
    @Override public boolean isSecondParam(){ return false; }
    @Override public boolean isThirdParam(){ return false; }
  };

  public abstract boolean isFirstParam();
  public abstract boolean isSecondParam();
  public abstract boolean isThirdParam();
}

https://docs.oracle.com/javase/8/docs/technotes/guides/language/enums.html has this to say:

The idea of adding behavior to enum constants can be taken one step further. You can give each enum constant a different behavior for some method. One way to do this by switching on the enumeration constant. Here is an example with an enum whose constants represent the four basic arithmetic operations, and whose eval method performs the operation:
public enum Operation {
    PLUS, MINUS, TIMES, DIVIDE;

    // Do arithmetic op represented by this constant
    double eval(double x, double y){
        switch(this) {
            case PLUS:   return x + y;
            case MINUS:  return x - y;
            case TIMES:  return x * y;
            case DIVIDE: return x / y;
        }
        throw new AssertionError("Unknown op: " + this);
    }
}
This works fine, but it will not compile without the throw statement, which is not terribly pretty. Worse, you must remember to add a new case to the switch statement each time you add a new constant to Operation. If you forget, the eval method with fail, executing the aforementioned throw statement

There is another way give each enum constant a different behavior for some method that avoids these problems. You can declare the method abstract in the enum type and override it with a concrete method in each constant. Such methods are known as constant-specific methods. Here is the previous example redone using this technique:
public enum Operation {
  PLUS   { double eval(double x, double y) { return x + y; } },
  MINUS  { double eval(double x, double y) { return x - y; } },
  TIMES  { double eval(double x, double y) { return x * y; } },
  DIVIDE { double eval(double x, double y) { return x / y; } };

  // Do arithmetic op represented by this constant
  abstract double eval(double x, double y);
}

Personally I don't mind throwing an exception and explicitly handling all posibilities, except if the switch would be located in the enum itself. The IDE gives me a warning (I can even configure it to turn it into an error so it won't compile) when you don't handle all cases. If you keep your projects warning free, which I try to do, you will immidiently know which files need their switch statements updated.

Best Answer

Related Solutions

Business Logic – Business Rules, Business Logic, Input Validation

Java Enums – Is switch(this) an Antipattern?

Related Topic