The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
В большинстве случаев (возможно, даже во всех) оператор if-then-else можно и должно заменить декоратором или просто другим объектом. Я собирался написать об этом уже почти год, но только сегодня обнаружил реальный случай в своем собственном коде, который иллюстрирует проблему в полной мере. Пришло время продемонстрировать и объяснить это.
Взгляните на класс DyTalk из yegor256/rultor и его метод modify(). Вкратце, он предотвращает сохранение любых данных в DynamoDB, если не было изменений в XML-документе. Это валидный случай, который должен быть проверен, но способ, которым это реализовано, просто неправильный. Вот как это работает (упрощенный пример):
Что не так, вы спрашиваете? Эта функциональность разветвления if-then-else на самом деле не относится к этому объекту - в этом и заключается проблема. Изменение XML-документа и сохранение его в базу данных - это его функциональность, в то время как не сохранение ничего, если набор инструкций по модификации пуст, - нет (это очень похоже на защитное программирование). Вместо этого должен быть декоратор, который будет выглядеть так:
Теперь, когда нам нужна более умная речь в ситуациях, когда список директив пуст, мы украшаем ее с помощью QuickTalk. Преимущества очевидны: класс DyTalk меньше и, следовательно, более согласован.
Но вопрос больше, чем просто это. Можем ли мы сделать из этого правило? Можем ли мы сказать, что каждое и любое разветвление плохо и должно быть вынесено из класса? А что насчет разветвления, которое происходит внутри метода и не может быть преобразовано в декоратор?
Я предлагаю следующее простое правило: если возможно преобразовать разветвление if-then-else в декоратор, это должно быть сделано. Если не сделано, это признак неудачного кода. Понятно?
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 10:44
