Сложность ПО, декомпозиция и объектно-ориентированный подход

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Архитектору Аналитику

Сложность ПО - декомпозиция и объектный подход

ООП часто преподают как синтаксис (class, extends, virtual). На практике объектная модель — способ уменьшить сложность: разрезать систему на части с ясными границами и ответственностью. Эта статья связывает три идеи из учебных программ: рост сложности, декомпозиция и ООП.

Концепции без привязки к языку — в введении в ООП. Синтаксис C++ — в ООП в C++. Парадигмы в целом — в стилях программирования.

---

Откуда берётся сложность

Сложность программы растёт не только из «много строк кода». Важнее связанность и непредсказуемость изменений:

Источник	Пример	Последствие
Размер	десятки модулей, сотни классов	трудно удержать картину целиком
Связанность	модуль A знает внутренности B	правка в B ломает A
Состояние	глобальные переменные, общие мутабельные структуры	гонки, трудно воспроизвести баг
Время	порядок инициализации, асинхронность	ошибки «иногда»
Домен	бизнес-правила меняются	код устаревает быстрее документации

Декомпозиция — осознанное разбиение системы на части так, чтобы каждая часть решала одну понятную задачу, а связи между частями были явными и узкими.

На уровне архитектуры это модули, сервисы, слои — см. практику проектирования. На уровне кода — функции, классы, пространства имён.

---

Декомпозиция — два масштаба

Логическая декомпозиция

Один исполняемый файл или репозиторий, но код разделён на пакеты/папки/namespace:

• auth — вход и токены;
• billing — оплата;
• notifications — письма и push.

Границы видны в структуре проекта. Зависимости можно ограничивать правилами (линтеры, arch-unit тесты).

Физическая декомпозиция

Отдельные процессы, БД, развёртывания — микросервисы, отдельные библиотеки. Снижает связанность на уровне runtime, но добавляет сеть, согласованность данных, observability. Подробнее: декомпозиция монолита.

ООП чаще всего работает на логическом уровне: класс — единица инкапсуляции внутри процесса.

---

Как ООП помогает с декомпозицией

ООП предлагает модель: объект = данные + операции над ними + скрытые правила целостности.

Приём ООП	Что даёт для сложности
Инкапсуляция	внешний код не трогает поля напрямую — меньше скрытых зависимостей
Абстракция	клиент видит «что делает», не «как устроено внутри»
Наследование	общий контракт для семейства типов (осторожно с глубокими иерархиями)
Полиморфизм	один интерфейс — разные реализации без if (type == …)

Пример: вместо функций draw_circle, draw_rectangle, draw_polygon с общим контекстом рисования — интерфейс Drawable и полиморфный вызов shape->draw(canvas). Новая фигура добавляется новым классом, а не правкой центрального switch.

Это не магия: плохо спроектированные иерархии увеличивают сложность (хрупкая база, «божественный объект»). Поэтому рядом с ООП идут SOLID и паттерны.

---

ООП не всегда лучший выбор

C++, Go, Rust и другие языки мультипарадигменные. Уместные альтернативы:

Ситуация	Часто лучше
Потоковая обработка данных	функции, конвейеры, map/filter
Скрипт, мало состояния	процедурный код
Жёсткие контракты типов без иерархий	struct + функции, traits, concepts
UI-состояние, реактивность	компоненты, события, FRP
Высокая производительность, мало полиморфизма	данные и алгоритмы отдельно (STL-стиль)

В C++ для отношения «содержит» чаще предпочитают композицию (поле-класс), а не наследование — см. композиция и наследование.

---

Практический чек-лист

Перед тем как вводить новый класс, спросите:

1. Одна ответственность? Можно ли описать класс одним предложением без «и»?
2. Инварианты? Есть ли правила, которые должны выполняться всегда (баланс ≥ 0, буфер не пуст при чтении)?
3. Граница изменений? Что будет меняться чаще — интерфейс или реализация?
4. Наследование нужно? Или достаточно поля Engine engine_ и делегирования?
5. Полиморфизм нужен? Нужен ли выбор реализации в runtime через общий базовый тип?

Если ответы размыты — возможно, достаточно функции и структуры данных.

---

Куда читать дальше

Тема	Материал
Класс, объект, четыре столпа	ООП — введение
C++: классы, наследование, STL	ООП в C++ и маршрут
Композиция вместо иерархий	141
Паттерны GoF	design-patterns
Итоги раздела	98

---