1. Обзор
Конструкции принятия решений являются важной частью любого языка программирования. Но при написании кода мы сталкиваемся с огромным количеством вложенных операторов if, которые делают наш код более сложным и трудным для сопровождения.
В этом уроке мы рассмотрим различные способы замены вложенных операторов if.
Давайте рассмотрим различные варианты того, как мы можем упростить код.
2. Практический пример
Часто мы сталкиваемся с бизнес-логикой, включающей множество условий, и каждое из них требует отдельной обработки. Для демонстрации возьмем пример класса Calculator. У нас будет метод, который принимает на вход два числа и оператор и возвращает результат на основе операции:
Мы также можем реализовать это с помощью операторов switch:
public int calculate(int a, int b, String operator) {
int result = Integer.MIN_VALUE;
if ("add".equals(operator)) {
result = a + b;
} else if ("multiply".equals(operator)) {
result = a * b;
} else if ("divide".equals(operator)) {
result = a / b;
} else if ("subtract".equals(operator)) {
result = a - b;
}
return result;
}
В типичной разработке if заявления могут стать намного больше и более сложными по своей природе. Кроме того, операторы switch плохо подходят для сложных условий.
public int calculateUsingSwitch(int a, int b, String operator) {
switch (operator) {
case "add":
result = a + b;
break;
// other cases
}
return result;
}
Другим побочным эффектом вложенных конструкций решений является то, что они становятся неуправляемыми. Например, если нам нужно добавить новый оператор, мы должны добавить новый оператор if и реализовать операцию.
3. Рефакторинг
Давайте рассмотрим альтернативные варианты замены сложных операторов if, приведенных выше, на гораздо более простой и управляемый код.
3.1. Фабричный класс
Много раз мы сталкиваемся с конструкциями решений, которые в конечном итоге выполняют одинаковую операцию в каждой ветви. Это дает возможность извлечь фабричный метод, который возвращает объект заданного типа и выполняет операцию на основе поведения конкретного объекта.
Для нашего примера давайте определим интерфейс Operation, который имеет единственный метод применения:
Метод принимает на вход два числа и возвращает результат. Давайте определим класс для выполнения дополнений:
public interface Operation {
int apply(int a, int b);
}
Теперь мы реализуем фабричный класс, который возвращает экземпляры операции на основе заданного оператора:
public class Addition implements Operation {
@Override
public int apply(int a, int b) {
return a + b;
}
}
Теперь в классе Calculator мы можем запросить factory для получения соответствующей операции и применения к исходным номерам:
public class OperatorFactory {
static Map<String, Operation> operationMap = new HashMap<>();
static {
operationMap.put("add", new Addition());
operationMap.put("divide", new Division());
// more operators
}
public static Optional<Operation> getOperation(String operator) {
return Optional.ofNullable(operationMap.get(operator));
}
}
В этом примере мы видели, как ответственность делегируется слабо связанным объектам, обслуживаемым классом factory. Но могут быть шансы, что вложенные операторы if просто переместятся в фабричный класс, что противоречит нашей цели.
public int calculateUsingFactory(int a, int b, String operator) {
Operation targetOperation = OperatorFactory
.getOperation(operator)
.orElseThrow(() -> new IllegalArgumentException("Invalid Operator"));
return targetOperation.apply(a, b);
}
В качестве альтернативы мы можем поддерживать репозиторий объектов на карте, который можно запрашивать для быстрого поиска. Как мы видели, OperatorFactory#operationMap служит нашей цели. Мы также можем инициализировать Map во время выполнения и настроить их для поиска.
3.2. Использование Enum
В дополнение к использованию Map мы также можем использовать Enum для маркировки определенной бизнес-логики. После этого мы можем использовать их либо во вложенных операторах if, либо в операторах switch case. В качестве альтернативы мы также можем использовать их в качестве фабрики объектов и разработать стратегию для выполнения соответствующей бизнес-логики.
Это также уменьшит количество вложенных операторов if и делегирует ответственность отдельным значениям Enum.
Давайте посмотрим, как мы можем этого добиться. Сначала нам нужно определить наш Enum:
Как мы видим, значения являются метками различных операторов, которые будут использоваться в дальнейшем для вычислений. У нас всегда есть возможность использовать значения в качестве различных условий во вложенных операторах if или в случаях переключения, но давайте разработаем альтернативный способ делегирования логики самому Enum.
public enum Operator {
ADD, MULTIPLY, SUBTRACT, DIVIDE
}
Мы определим методы для каждого из значений Enum и проведем вычисления. Например:
Затем в классе Calculator мы можем определить метод для выполнения операции:
ADD {
@Override
public int apply(int a, int b) {
return a + b;
}
},
// other operators
public abstract int apply(int a, int b);
Теперь мы можем вызвать метод, преобразовав значение String в оператор, используя Метод Operator#valueOf():
public int calculate(int a, int b, Operator operator) {
return operator.apply(a, b);
}
3.3. Шаблон команды
@Test
public void whenCalculateUsingEnumOperator_thenReturnCorrectResult() {
Calculator calculator = new Calculator();
int result = calculator.calculate(3, 4, Operator.valueOf("ADD"));
assertEquals(7, result);
}
В предыдущем обсуждении мы видели использование класса фабрики для возврата экземпляра правильного бизнес-объекта для данного оператора. Позже бизнес-объект используется для выполнения вычислений в калькуляторе.
«Мы также можем разработать метод Calculator#calculate для приема команды, которая может выполняться на входах. Это будет еще один способ замены вложенных операторов if.
Сначала мы определим наш командный интерфейс:
Затем давайте реализуем AddCommand:
public interface Command {
Integer execute();
}
Наконец, давайте представим новый метод в калькуляторе, который принимает и выполняет команду: ~~ ~
public class AddCommand implements Command {
// Instance variables
public AddCommand(int a, int b) {
this.a = a;
this.b = b;
}
@Override
public Integer execute() {
return a + b;
}
}
Затем мы можем вызвать вычисление, создав экземпляр AddCommand и отправив его в метод Calculator#calculate:
public int calculate(Command command) {
return command.execute();
}
3.4. Механизм правил
@Test
public void whenCalculateUsingCommand_thenReturnCorrectResult() {
Calculator calculator = new Calculator();
int result = calculator.calculate(new AddCommand(3, 7));
assertEquals(10, result);
}
Когда мы в конечном итоге напишем большое количество вложенных операторов if, каждое из условий отображает бизнес-правило, которое необходимо оценить для правильной логики обработки. Механизм правил избавляет основной код от такой сложности. RuleEngine оценивает правила и возвращает результат на основе ввода.
Давайте рассмотрим пример, разработав простой RuleEngine, который обрабатывает выражение через набор правил и возвращает результат из выбранного правила. Во-первых, мы определим интерфейс Rule:
Во-вторых, давайте реализуем RuleEngine:
public interface Rule {
boolean evaluate(Expression expression);
Result getResult();
}
RuleEngine принимает объект Expression и возвращает результат. Теперь давайте создадим класс Expression как группу из двух объектов Integer с оператором, который будет применяться:
public class RuleEngine {
private static List<Rule> rules = new ArrayList<>();
static {
rules.add(new AddRule());
}
public Result process(Expression expression) {
Rule rule = rules
.stream()
.filter(r -> r.evaluate(expression))
.findFirst()
.orElseThrow(() -> new IllegalArgumentException("Expression does not matches any Rule"));
return rule.getResult();
}
}
И, наконец, давайте определим собственный класс AddRule, который оценивается только тогда, когда указана операция ADD:
public class Expression {
private Integer x;
private Integer y;
private Operator operator;
}
~ ~~ Теперь мы вызовем RuleEngine с выражением:
public class AddRule implements Rule {
@Override
public boolean evaluate(Expression expression) {
boolean evalResult = false;
if (expression.getOperator() == Operator.ADD) {
this.result = expression.getX() + expression.getY();
evalResult = true;
}
return evalResult;
}
}
4. Заключение
@Test
public void whenNumbersGivenToRuleEngine_thenReturnCorrectResult() {
Expression expression = new Expression(5, 5, Operator.ADD);
RuleEngine engine = new RuleEngine();
Result result = engine.process(expression);
assertNotNull(result);
assertEquals(10, result.getValue());
}
В этом руководстве мы рассмотрели несколько различных вариантов упрощения сложного кода. Мы также узнали, как заменить вложенные операторы if с помощью эффективных шаблонов проектирования.
Как всегда, мы можем найти полный исходный код в репозитории GitHub.
«