Перейти к Гиду по Лабе №2 → ИТМО • 3 Семестр

Архитектурный фундамент SOLID (5) GRASP (Craig Larman)

Принципы SOLID и GRASP в ООП C#

Полный теоретический путеводитель по каноническим принципам проектирования: подробный разбор каждого принципа, визуальные схемы, антипаттерны, примеры кода на C# и корреляция между SOLID и GRASP по программе кафедры ИТМО.

Single Responsibility Principle (SRP) — Принцип единственной ответственности

Роберт Мартин

📌 Дословная формулировка из презентации лекций:

«Проектирование типов, таким образом что они имеют единственную причину для изменения»

Классический вариант Роберта Мартина: «A class should have one, and only one, reason to change». Под модулем на кафедре понимается любой тип в коде, инкапсулирующий логику и состояние.

❌ Нарушение SRP (Класс-бог):

Класс Tare сам хранит товары, сам считает весы, сам лезет в базу данных и сам проверяет товарное соседство через правила пожарной безопасности.

Причина проблемы: изменился формат БД — меняем Tare. Изменились правила пожарников — опять меняем Tare.

✅ Соблюдение SRP (Декомпозиция):

Tare отвечает только за состояние тары. Проверка совместимости вынесена в NeighborhoodValidator. Сохранение — в ITareRepository.

Каждый класс меняется только по своей единственной изолированной причине.

Open/Closed Principle (OCP) — Принцип открытости / закрытости

Бертран Мейер

📌 Дословная формулировка из презентации лекций:

«Проектирование типов, таким образом что их логику можно расширять, не изменяя их исходный код.
Тип должен быть открытым для расширения, но закрытым для изменений»

Мы должны иметь возможность добавлять в систему новое поведение без переписывания и правки существующего протестированного кода.

❌ Нарушение OCP:

Внутри сервиса написан гигантский switch (ruleType). Чтобы поддержать правило проверки срока годности, приходится лезть внутрь существующего метода и дописывать новый case, рискуя сломать старое.

✅ Соблюдение OCP:

Выделен интерфейс IDistributionRule. Новое поведение добавляется созданием нового класса (например, ExpirationRuleDecorator), а старые классы тар и палет не меняются ни на символ.

Liskov Substitution Principle (LSP) — Принцип подстановки Барбары Лисков

Барбара Лисков

📌 Дословная формулировка из презентации лекций:

«Проектирование иерархий типов, таким образом что логика дочерних типов не нарушает инвариант и интерфейс родительских типов»

Классический пример нарушения: «Квадрат наследуется от Прямоугольника». При изменении ширины у квадрата неявно меняется и высота, что ломает тесты, рассчитывающие на поведение обычного прямоугольника.

В нашем проекте: любое правило (TareDistributionRule, PalletDistributionRule, декоратор) можно подставить в любое место, ожидающее IDistributionRule. Ни один потомок не бросает неожиданных исключений вроде NotImplementedException и не меняет контракт контракта.

Interface Segregation Principle (ISP) — Принцип разделения интерфейса

Роберт Мартин

📌 Дословная формулировка из презентации лекций:

«Проектирование маленьких абстракций, которые ответственны за свой конкретный функционал, а не одной всеобъемлющей, содержащей много различного»

Назначение ISP по презентации: правило для корректного проектирования связей между типами.

❌ «Жирный» интерфейс:

              interface IWarehouseManager {

                void Log(string msg);

                DateTime GetTime();

                bool CheckNeighbor();

                void SaveTare();

              }

Класс, которому нужно только логирование, вынужден зависеть от методов работы с БД и временем.

✅ Узкие интерфейсы (Как у нас):

              interface IRuleLogger { void Log(...); }

              interface ITimeProvider { DateTimeOffset GetCurrentTime(); }

              interface INeighborhoodValidator { bool CanBePlacedTogether(...); }

Каждый потребитель зависит ровно от того метода, который ему действительно нужен.

Dependency Inversion Principle (DIP) — Принцип инверсии зависимостей

Роберт Мартин

📌 Дословная формулировка из презентации лекций:

«Проектирование типов, таким образом что одни реализации не зависят от других напрямую»

Классическая развертка по Мартину: модули верхних уровней не должны зависеть от модулей нижних уровней (оба зависят от абстракций); абстракции не зависят от деталей реализации.

Аналогия с разъёмом USB-C: Телефон не припаян к розетке на стене. Телефон зависит от абстрактного интерфейса разъёма USB-C. С другой стороны шнура может быть розетка 220V, повербанк или прикуриватель авто.

В нашем коде: TareService не создаёт базу данных сам через new Database(). Он принимает интерфейс ITareRepository через конструктор. В тестах мы подставляем InMemoryTareRepository без реальной базы данных.

🧩 Что такое GRASP?

GRASP (General Responsibility Assignment Software Principles) — общие принципы распределения ответственностей в ПО.
Цитата со слайдов: «GRASP рассматривает те же проблемы, что и SOLID, но с немного другой стороны. SOLID — таблица умножения от мира ООП, а модуль — самодостаточная единица системы, реализующая определённый функционал, инкапсулирующая логику и состояние».

1. Information Expert (Информационный эксперт)

Формулировка с лекции: «Информация должна обрабатываться там, где она содержится»

Где у нас: Кто должен вычислять текущий занятый ОВХ тары (CurrentOvh)? Класс Tare, потому что именно он держит коллекцию Items. Неправильно было бы заставлять внешний сервис бегать и собирать веса руками.

2. Low Coupling (Слабое зацепление / Низкая связанность)

Формулировка с лекции (Coupling): «Мера зависимости модулей друг между другом» (стремимся к Low Coupling — слабой зависимости).

Где у нас: Палета не знает внутреннего устройства тары, а тары не знают про палету. Правило палеты общается с правилами тар только через фасадный метод Distribute(Item).

3. High Cohesion (Высокая сплочённость)

Формулировка с лекции (Cohesion): «Мера логической соотнесённости логики в рамках модуля» (стремимся к High Cohesion — высокой связности задач внутри одного класса).

Где у нас: Валидатор NeighborhoodValidator не занимается поиском тары в репозитории и взвешиванием товара. Он сфокусирован только на одном вопросе: совместимы ли товарные группы?

4. Pure Fabrication (Чистая выдумка)

Формулировка с лекции: «Подразумевает наличие в системе искусственной, выдуманной сущности, не отражающей конкретный объект моделируемых бизнес процессов. Обычно это инфраструктурные модули, сервисы. Не рекомендуется вносить такие типы в доменную модель»

Где у нас: На реальном складе нет физического предмета «ВалидаторСоседства» или «СервисТар». Но мы создаём эти классы в коде, чтобы разгрузить сущности Tare и Sku.

5. Indirection (Посредник / Перенаправление)

Object Indirection (с лекции): «Любое взаимодействие с данными, поведениями, модулями, реализованное не напрямую, а через какой-либо агрегирующий их объект»

Interface Indirection (с лекции): «Любое взаимодействие с данными, поведениями, модулями, реализованное не напрямую, а через какой-либо интерфейс»

Где у нас: TareDistributionRule является посредником между клиентом дерева правил и внутренним сервисом TareService.

6. Protected Variations (Защита от изменений)

Формулировка с лекции: «Подразумевает выделение стабильного интерфейса над нестабильной реализацией. Коррелирует с OCP из SOLID, делает больший акцент на определение точек нестабильности»

Где у нас: Интерфейсы ITimeProvider и IRuleLogger защищают доменную логику: завтра консольный вывод можно заменить на Serilog или ElasticSearch, не трогая правила.

Мост: Как связаны принципы SOLID и GRASP?

На экзаменах и защитах в ИТМО обожают задавать вопрос: «А чем GRASP отличается от SOLID, и как они пересекаются?». Вот шпаргалка соответствия:

Принцип SOLID	Соответствующий паттерн GRASP	В чём общая суть?
SRP (Single Responsibility)	High Cohesion (Высокая сплочённость)	Класс сфокусирован на одной задаче и имеет одну причину для изменений.
OCP (Open-Closed)	Protected Variations (Защита от изменений)	Закрываем точки нестабильности за стабильными интерфейсами (новые правила расширяют поведение, не ломая старое).
DIP (Dependency Inversion)	Low Coupling & Indirection	Устраняем прямую зависимость от реализаций, вводя интерфейсы-посредники.
DIP + SRP	Pure Fabrication (Чистая выдумка)	Выносим системную логику (логирование, репозитории, валидаторы) в искусственные сервисы.

Топ вопросов преподавателей по слайдам презентаций

Ответы основаны на материалах лекций курса ООП в ИТМО.

1. В чём разница между Coupling (связанность) и Cohesion (сплочённость)?

Coupling (зацепление/связанность) — это степень взаимозависимости между разными модулями (мы стремимся к Low Coupling, чтобы модули можно было легко переиспользовать и тестировать отдельно).
Cohesion (сплочённость) — это мера того, насколько сильно элементы внутри одного модуля связаны друг с другом по смыслу (мы стремимся к High Cohesion, чтобы класс не делал «всё подряд»).

2. Чем Декоратор (Decorator) отличается от Прокси (Proxy)? (Слайды 86–90)

Оба паттерна имеют одинаковую структуру (оборачивают исходный объект и реализуют тот же интерфейс). Разница в намерении (Intent):

Декоратор: добавляет новую динамическую функциональность (например, проверку срока годности или форматированный лог). Клиент сам решает, как комбинировать декораторы («слоёный пирог»).
Прокси: управляет доступом к объекту (Lazy Loading — создание объекта только при вызове, защита прав доступа, кэширование, вызов по сети). Обычно прокси сам управляет жизненным циклом своего служебного объекта.

3. Почему Information Expert не должен превращаться в класс-бог (God Object)?

Если бездумно пихать всю логику туда, где лежат данные, мы получим гигантский монолит с низкой сплочённостью (Low Cohesion). Чтобы этого избежать, мы балансируем Information Expert с принципом Pure Fabrication — выносим бизнес-процессы (как проверка товарного соседства или координация добавления) в специализированные сервисы.