Принципы ОО-проектирования перед паттернами
Паттерны 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 в клиенте — на фабрику. Подробнее о том, когда паттерн лишний, — в обзоре раздела.
См. также
См. также
Другие статьи этого же раздела в боковом меню (как на странице "О разделе"). Паттерн — это повторяющийся шаблон, узор или схема. Паттерны встречаются повсюду — в природе, архитектуре, поведении людей и, конечно, в программировании. Порождающие паттерны проектирования — это группа шаблонов, направленных на решение задач, связанных с созданием объектов. Структурные паттерны — это группа шаблонов проектирования, решающих задачи организации классов и объектов таким образом, чтобы обеспечить гибкую архитектуру программного обеспечения. Поведенческие паттерны — это группа шаблонов проектирования, которые определяют способы взаимодействия объектов и распределения ответственности между ними. Архитектурные паттерны — это проверенные решения для организации структуры программного обеспечения. Интеграция систем — одна из центральных задач в современной разработке программного обеспечения. Паттерны доменного моделирования представляют собой проверенные решения для организации бизнес-логики в программных системах. Паттерн Strategy в C# — классическая реализация через интерфейс, замена на Func и Action, DI и критерии выбора без лишних абстракций. Паттерн Iterator в C# — ручной IEnumerator, генерация итератора компилятором через yield return, ленивость, LINQ и случаи, когда класс писать всё же нужно. Abstract Factory в C# и .NET — классическая схема через интерфейсы, замена через DI-контейнер, фабричный делегат и keyed services в .NET 8. Паттерн Command в C# — классическая схема, делегаты, MediatR, очередь задач, undo и критерии выбора между объектом команды и простым вызовом сервиса. Паттерн Observer в C# — event и делегаты, IObservable IObserver, слабая связанность, отписка и как не поймать утечки памяти в долгоживущих сервисах.Обзор паттернов проектирования
Порождающие паттерны
Структурные паттерны
Поведенческие паттерны
Архитектурные паттерны
Паттерны интеграции внешних систем
Паттерны проектирования доменных моделей
Стратегия в C#
Итератор в C#
Фабрика в C#
Команда в C#
Наблюдатель в C#