Дизайн‑паттерны помогают при рефакторинге большого кода, потому что они формализуют повторяющиеся архитектурные решения: инкапсулируют создание объектов и конфигурацию, уменьшают дублирование, ослабляют связность и делают зависимости явными — это повышает читаемость и облегчает модульное тестирование.
Ниже — два коротких практических примера (проблема → как паттерн меняет код → почему становится чище и тестируемее).
Фабричный метод (Factory Method)
- Проблема: в коде в многих местах есть ветвления по типу для создания конкретных реализаций; логика создания разбросана и напрямую создаёт зависимости, что мешает мокать и расширять.
- Решение: выделить фабрику/метод создания в отдельный интерфейс и внедрять его через DI.
Пример (до):
```
if (type.equals("A")) {
service = new ServiceA(dep1, dep2);
} else if (type.equals("B")) {
service = new ServiceB(dep1, dep3);
}
// похожая логика повторяется в нескольких местах
```
После (Factory Method):
```
interface ServiceFactory {
Service create();
}
class ServiceAFactory implements ServiceFactory {
Service create() { return new ServiceA(dep1, dep2); }
}
class ServiceBFactory implements ServiceFactory {
Service create() { return new ServiceB(dep1, dep3); }
}
// В коде:
Service service = injectedFactory.create();
```
Преимущества для рефакторинга и тестов:
- Создание централизовано — легче изменить конструкцию одного класса.
- Внедрение фабрики позволяет подменять реализацию в тестах простым mock/stub (подставить тестовую фабрику).
- Новый тип можно добавить, добавив новую фабрику, не изменяя вызовы создания по всему проекту.
Builder (Строитель)
- Проблема: объекты с множеством опциональных/параметров конструктора → «телескопические» конструкторы или длинный список аргументов; создание в тестах и чтение кода становятся неудобными и ошибкоопасными.
- Решение: применить Builder — читабельный fluent API и возможность задавать разумные дефолты для тестов.
Пример (до):
```
User u = new User("Ivan", "Ivanov", true, 42, null, "Moscow", false);
```
(трудно понять, что за параметры и в тестах приходится дублировать множество полей)
После (Builder):
```
User u = new User.Builder()
.firstName("Ivan")
.lastName("Ivanov")
.active(true)
.age(42)
.city("Moscow")
.build();
```
Дополнительно для тестов:
- Сделать TestUserBuilder с разумными дефолтами:
```
User user = new TestUserBuilder().withAge(18).build();
```
Это уменьшает шаблонный код в тестах и делает тесты устойчивыми к добавлению новых полей (добавили новое опциональное поле — тесты не сломаются, пока дефолт устроит).
Почему это улучшает рефакторинг:
- Эксплицитная конфигурация объектов упрощает понимание вызовов.
- Менее хрупкие тесты (меньше нужды менять все фабрики/места создания при добавлении параметров).
- Можно разделить обязанность «создания/конфигурации» и «использования», что облегчает пошаговое изменение большого кода.
Вывод (коротко):
- Factory Method полезен, когда нужно централизовать и параметризовать создание разных реализаций и сделать замену реализаций простой для тестов.
- Builder полезен для объектов с множеством параметров и для упрощения подготовки тестовых данных.
Оба паттерна делают код более модульным, уменьшают дублирование и значительно облегчают написание и сопровождение модульных тестов.