Принципы ОО-проектирования перед паттернами
Модель и масштаб — Основы БД, опорные темы, проектирование БД, пакетная работа. Карта — о разделе.
Паттерны GoF — именованные схемы, которые уже следуют здравому ОО-проектированию. Если сначала выучить только названия (Strategy, Factory, Observer), легко начать "накручивать" классы без понимания, зачем они появились. Ниже — четыре опорных принципа, на которых обычно строят вводные курсы по паттернам, в инженерной формулировке и со связью с SOLID.
Эта статья → десять частых паттернов → узкие главы по языку (C#, Java) → составные паттерны и MVC.
Полный справочник GoF — в большом гиде.
Четыре опорных принципа
| Принцип | Суть | Типичный симптом нарушения |
|---|---|---|
| Инкапсулируйте то, что изменяется | Всё, что может меняться по требованиям, выносите в отдельные части (поля, классы, интерфейсы) | Один if на новый тип утки/оплаты/канала в десяти методах |
| Предпочитайте композицию наследованию | Поведение собирайте из объектов, а не только из глубокой иерархии субклассов | Резиновая утка "наследует" fly(), хотя летать не должна |
| Программируйте на уровне интерфейсов | Клиент зависит от абстракции (FlyBehavior, PaymentMethod), а не от MallardDuck | Метод принимает PostgresRepository, хотя нужен любой Repository |
| Стремитесь к слабой связанности | Модули знают друг о друге минимум, нужный для работы | Изменение в модели ломает пять UI-компонентов |
Эти четыре правила — не замена SOLID, а лестница к нему — их проще запомнить на старте, а затем уточнить формулировками Мартина (SRP, OCP, LSP, ISP, DIP).
Связь с SOLID
| Опорный принцип | Ближайший SOLID | Паттерн, который иллюстрирует идею |
|---|---|---|
| Инкапсуляция изменений | O (открытость/закрытость) | Декоратор, Стратегия |
| Композиция вместо наследования | L (подстановка Лисков) | Стратегия, Декоратор |
| Интерфейсы вместо классов | D (инверсия зависимостей) | Фабричный метод, DI в Фабрике C# |
| Слабая связь | I + D | Наблюдатель, Фасад |
| (дополнительно в книге) Единственная ответственность | S | Разделение Model / View / Controller в MVC |
Полный разбор с примерами кода — в статье Принципы SOLID.
Дополнительные правила на ревью
К четырём опорным принципам на практике добавляют уточнения из SOLID и повседневного проектирования:
- Принцип открытости/закрытости — расширяйте поведение без правки стабильного кода (Декоратор).
- Инверсия зависимостей — высокоуровневые модули не зависят от деталей создания объектов (порождающие паттерны).
- Принцип наименьшего знания — объект общается только с ближайшими "друзьями" (Фасад, Адаптер).
- Голливудский принцип — "не звоните нам, мы вам позвоним": фреймворк вызывает ваши хуки, а не наоборот (Шаблонный метод).
- Единственная ответственность — один повод для изменения на класс (разделение Model / View / Controller в MVC).
Сначала простой код, потом паттерн
Учебник подчёркивает: паттерн — инструмент по необходимости, а не цель архитектуры. Практичный порядок действий:
- Напишите самое простое решение, которое проходит тесты и читается командой.
- Отметьте, что в коде меняется чаще всего (алгоритмы, UI, интеграции, правила состояний).
- Примените один из четырёх принципов выше (часто достаточно вынести интерфейс или композицию).
- Если схема повторяется в проекте и в индустрии — дайте ей имя из GoF и согласуйте с командой.
Рефакторинг — естественная точка для паттернов: длинные switch по состоянию намекают на Состояние, жёсткие new в клиенте — на фабрику. Подробнее о том, когда паттерн лишний, — в обзоре раздела.