Новые требования сообщают две вещи:
- Уточнение того, что именно должен делать код. Эта информация показывает, каким образом должен был быть написан код.
- Повышение требований к изменяемости кода. После реализации нового требования код должен быть более приспособлен к такого рода изменениям, чем раньше. Приспособление кода к будущим изменениям такого рода осуществляется на основе OCP - принципа открытости/закрытости.
Если код, в который нужно добавить новую функциональность, не является “открытым для расширения”, нужно сначала провести рефакторинг, подготовив его к новой функциональности.
Общая схема такова:
- Код “открыт для расширения”?
- Если да, то добавить новый расширяющий код.
- Понятно, как сделать код “открытым для расширения”?
- Если да, то сделать код открытым, а потом добавить расширяющий код.
- Рефакторить самый простой или самый понятный “запах кода”.
При этом нельзя смешивать процессы рефакторинга и добавления новых фич. Эффективная работа с унаследованным кодом#^code-change-reasons, #FeathersMichael уточняет, что это два очень разных процесса внесения изменений в код.
Своего рода метрики для следования принципу OCP приведены в
Архитектура ПО в Spring 5:
- Какие изменения понадобится внести, чтобы добавить новую функциональность? В
идеале модифицировать существующий код нужно очень незначительно. В основном
новая функциональность должна быть сосредоточена в новых классах, реализующих
существующие интерфейсы. Уточнения:
- Нужно ли добавить новые операторы
if? Нет (или один - в том месте, где проходит “шов” в терминологии #FeathersMichael ). - Как много существующего кода нужно изменить? Совсем чуть-чуть.
- Насколько большими должны быть отдельные файлы исходников? Маленькими.
- Нужно ли использовать абстракции? В пределах разумного. Интерфейс для единственной имплементации не нужен.
- Нужно ли добавить новые операторы