Проверяет понимание альтернатив громоздкому switch-case при реализации расширяемого движка правил.
Когда количество правил растёт, switch-case становится трудно поддерживать: каждое новое правило требует изменения центрального метода, что нарушает принцип открытости/закрытости и увеличивает риск ошибок.
Базовый подход — определить интерфейс Rule с методом evaluate(context). Каждое правило реализует этот интерфейс. Движок хранит список правил и вызывает их по очереди. Добавление нового правила — просто новый класс, удаление — исключение из списка.
interface Rule {
boolean evaluate(Context ctx);
}
class AgeRule implements Rule {
public boolean evaluate(Context ctx) {
return ctx.age > 18;
}
}
class Engine {
List<Rule> rules = new ArrayList<>();
void addRule(Rule r) { rules.add(r); }
void removeRule(Rule r) { rules.remove(r); }
}Стратегия — частный случай полиморфизма, когда алгоритмы взаимозаменяемы. Здесь каждое правило — стратегия, выбираемая динамически. Это удобно, когда правила могут комбинироваться или выбираться по условию.
Можно использовать Map, где ключ — условие (например, тип события), значение — функция-обработчик. Это похоже на switch, но данные отделены от логики, и правила можно добавлять из конфигурации.
Map<String, Function<Context, Boolean>> rules = new HashMap<>();
rules.put("age", ctx -> ctx.age > 18);
rules.put("vip", ctx -> ctx.isVip);
boolean apply(String ruleName, Context ctx) {
return rules.get(ruleName).apply(ctx);
}Используйте полиморфизм или реестр, когда правила часто меняются или их много. Это делает код гибким, тестируемым и легко расширяемым, особенно в системах с бизнес-логикой, где правила могут добавляться без перекомпиляции основного модуля.
