Элегантный способ заменить несколько, если государственные деятели бросают исключения - PullRequest
Новая
       46

Элегантный способ заменить несколько, если государственные деятели бросают исключения

0 голосов
/ 11 февраля 2019

В моем приложении есть служба, в которой 3 метода выполняют некоторую проверку и в зависимости от возвращаемого результата выдается другое исключение. 

  if (!check1stCondition() {
    throw new ValidationException(message1);
  }

  if (!check2ndCondition)
    throw new ValidationException(message2);

  if (!check3rdCondition)
    throw new ValidationException(message3);
}

Как я могу переформатировать этот код, чтобы его можно было обслуживать в будущем?В будущем могут быть выполнены новые проверки.

Ответы [ 4 ]

0 голосов
/ 11 февраля 2019

Есть путь, близкий к ООП.Примечание: я не настаиваю на этом, просто показываю альтернативу.

Сначала вы можете создать новый класс для каждого условия.И при условии, что вы выполняете проверку некоторых данных, они будут выглядеть следующим образом: 

interface Condition {
    CustomData checkedData();
}

public class Condition1 implements Condition {
    private CustomData data;

    public Condition1(CustomData data) {
        this.data = data;
    }

    public Condition1(Condition condition) {
        this.data = condition.checkedData();
    }

    public CustomData checkedData() {
        // do condition checking here and return CustomData if it's ok
        // throw exception otherwise
    }
}

Затем вы можете обернуть каждый Condition в другой: 

CustomData data = new Condition1(
                      new Condition2(
                          new Condition3(YOUR_DATA))).checkedData();

Теперь вы будете уверены, что вашданные проверены и готовы к дальнейшей работе.

Я считаю, что их легко поддерживать ... если вам нужно несколько новых проверок, просто добавьте несколько небольших классов, как указано выше, и оберните ваши данные в другой Condition.Если вы хотите изменить какое-либо условие, вам не нужно искать его в общем коде.У вас есть отдельный класс для этого.

0 голосов
/ 11 февраля 2019

Я вижу, что у вас есть 3 разных условия с 3 разными сообщениями.Стоит использовать что-то вроде предварительных условий для гуавы или написать свое собственное.

Вашему коду будет нравиться 

checkState(check1stCondition(), message1);
checkState(check2stCondition(), message2);

Вы не будете полностью уменьшать if's.Но, по крайней мере, вы повышаете читабельность.

0 голосов
/ 11 февраля 2019

Вы можете попытаться использовать полиморфизм, чтобы уменьшить операторы if и улучшить удобство обслуживания.

Просто используйте такой интерфейс 

public interface Example {

void check() throws ValidationException;
}

и реализуйте различные варианты поведения.

0 голосов
/ 11 февраля 2019

Вы можете определить интерфейс Checker, предоставляющий метод check, исключающий исключение, когда оно имеет место.Ваш код может измениться на что-то вроде 

public interface Checker {
    void check() throws ValidationException;
}

public class YourClass {
   private List<Checker> checkers; // initialize through (dependency inhecjetd?) constructor parameter or by simply enumerating checker in the constructor; I personally prefer the first way

   public void yourMethod() {
     for(Checkech checker : checkers) {
        checker.check();
     }
   }
}

Очевидно, что вы можете добавить параметры в метод check, чтобы предоставить данные для проверки ...

ОБНОВЛЕНО

Если у вас есть точка управления реализацией проверки условий, вы можете переключиться на что-то вроде этого (см. Комментарий @Alberto Venturini): 

public interface Checker {
    boolean check();

    String message();
}

public class YourClass {
   private List<Checker> checkers; // initialize through (dependency inhecjetd?) constructor parameter or by simply enumerating checker in the constructor; I personally prefer the first way

   public void yourMethod() {
     for(Checkech checker : checkers) {
        if(!checker.check()) {
            throw new ValidationException(checker.message());
        }        
     }
   }
}

Вы можете реализовать подобное решение с первым определением Checker, используяпеременная Map<String, Checker>, которая поддерживает ассоциации между условиями проверки и соответствующим сообщением об ошибке, но я определенно предпочитаю полиморфный подход, предложенный @Alberto Venturini.

Я надеюсь, что этот подход может помочь вам переместить ваш код к более открытомурешение!

...