Рефакторинг подход, чтобы очистить многие если с помощью java лямбда - PullRequest
Новая
       42

Рефакторинг подход, чтобы очистить многие если с помощью java лямбда

0 голосов
/ 19 января 2020

В настоящее время я занимаюсь уборкой, которую трудно обслуживать и проверять, не является ли еще беспорядок, основанный на условиях, которые должны быть проверены в изоляции:

Что является основой c семанти c условий?

Большие объекты сущности должны проверяться на основе двух ключей сущности, а именно Trans и Right для изменения состояния, как в примере ниже: 

if (oldTrans.getfOrder().equals(newTrans.getfOrder()) {
     compound.setIsStateChanged(true);
      return;
}
if (oldRight.getfRight().equals(newRight.getfRight()) {
     compound.setIsStateChanged(true);
}

В настоящее время if else все загромождены в одном месте: 

    if (oldTrans.getfOrder().equals(newTrans.getfOrder()) {
        compound.setIsStateChanged(true);
        LOGGER.info("major change detected");
        return compound;
    } if (oldTrans.getgOrder().equals(newTrans.getgOrder()) {
        compound.setIsStateChanged(true);
LOGGER.info("major change detected");
        return compound;   
    }

Я вижу здесь 2 основных вопроса

  1. Каждый if имеет оператор return и так много if, что его трудно узнать когда и какой метод точки указывают на выход.

  2. Для многих, если ответвления подвержены ошибкам, и число условий, вероятно, увеличится на go.

Чтобы избежать множества if, основанных на одной и той же семантике c снизу с точки зрения чистого кода, я попытался решить ее полиморфом c way

Извлечение условий в Enums как констант и добавление шашка я Интерфейс, который принимает новые и старые объекты в качестве параметров 

    public interface ICheckStateChange<T>(T old, T new) {
        boolean check(T old, T new);
    }

    //implementations
    public TransChecker implements ICheckStateChange<Trans> {

      List<BiPredicate<Trans, Trans>> allTransConditions = transConditions.getValues();

    public boolean check(Trans oldTrans, Trans newTrans) {
         //all conditions null check here
        //loop through conditions
        for (BiPredicate<Trans, Trans> transCondition: allTransConditions) {
            if (transCondition).test()) {
                return true;
             LOGGER.info("major state change detected, taking apt action")
          }
    }

public RightChecker implements ICheckStateChange<Right> {

      List<BiPredicate<Right, Right>> allTransConditions = RightConditions.getValues();

    public boolean check(Right oldRight, Right newRIght) {
         //all conditions null check here
        //loop through conditions
        for (BiPredicate<Right, Right> rightCondition: allRightConditions) {
            if (rightCondition).test()) {
                return true;
             LOGGER.info("major state change detected, taking apt action")
          }
    }

В настоящее время Conditons расположены в центре как константы BiPredicate, используя лямбды 

public enum rightConditions {
    FORDER_CHANGE_NULL_TO_NOT_NULL((Order old, Order new)
       -> old == null && new != null),

    //to be replaced by the right condition
    GORDER_CHANGE_FROM_OPEN_TO_DONE((Order old, Order new)
       -> old == null && new != null)

    //to be replaced by the right condition
    LORDER_CHANGE_FROM_OPEN_TO_REVERTED((Order old, Order new)
       -> old == null && new != null)

........
   }

Мой вопрос здесь о подходе рефакторинга Если еще с помощью лямбда-бипредикатов задним числом чистый код? Читабельность, расширяемость и ремонтопригодность ;)

...