Процедурный стиль
- Идея: данные и операции разделены — есть структуры данных (например, запись Document с полями text, cursor, selection) и набор функций, которые изменяют эти структуры.
- Управление состоянием: состояние обычно изменяемое и глобально или передаётся по ссылке/указателю в функции; функции выполняют побочные эффекты напрямую (изменяют поле text, обновляют курсор). Часто используется общий модуль состояния.
- Расширяемость: добавление новой операции — добавление новой функции; расширение формата документа или поведения часто требует правок в центральных функциях (меньше инкапсуляции). Можно организовать таблицы функций/колбэки для плагинов, но это менее структурировано.
- Тестируемость: тесты проще для чистых вспомогательных функций; функции, меняющие глобальное состояние, сложнее тестировать — требуется подготовка/сброс состояния или мокирование окружения; модульность функций облегчает unit‑тесты, но побочные эффекты усложняют изоляцию.
Объектно‑ориентированный стиль
- Идея: данные и поведение объединены в объекты (например, класс Document с методами insert, delete, format). Объект инкапсулирует состояние и инварианты.
- Управление состоянием: состояние инкапсулировано в экземплярах; изменение состояния происходит через методы; для сложных сценариев используют паттерны (Command для undo/redo, Observer для обновления UI, Memento для снимков).
- Расширяемость: полиморфизм, интерфейсы и наследование позволяют добавлять новые типы документов/поведения без правки существующего кода; стратегии/шаблонные методы и плагины через интерфейсы дают гибкость.
- Тестируемость: методы удобно мокировать и подменять зависимости (dependency injection); unit‑тесты на уровне объектов просты, но внутренние мутабельные состояния могут делать тесты хрупкими — требуются хорошо определённые контракты и слабая связанность.
Функциональный стиль
- Идея: система строится из чистых функций и неизменяемых данных; операции принимают Document и возвращают новый Document; побочные эффекты централизуются на границах (ввод/вывод, состояние UI).
- Управление состоянием: состояние не изменяется в месте — используются иммутабельные структуры (persistent data structures) и явное возвращение новых версий документа; для контроля эффектов применяются абстракции (State/IO/Effect‑монады, эффекты/алгебры).
- Расширяемость: легко составлять и комбинировать маленькие чистые трансформации; добавление новых операций — добавление функций/комбинаторов; при использовании ADT (алгебраических типов) расширение по операциям или по вариантам требует разных подходов (pattern matching vs новые интерпретаторы), но композиция остаётся мощной.
- Тестируемость: высокий уровень тестируемости — чистые функции детерминированы и легко unit‑ и property‑тестируются; меньшая потребность в моках; интеграционные тесты требуются только для эффектных границ.
Короткое сравнение (ключевые компромиссы)
- Управление состоянием: процедурный и ООП — мутабельность и локальные изменения; функциональный — иммутабельность и явное управление эффектами.
- Расширяемость: ООП хорошо для расширения поведения через интерфейсы/наследование; функциональный хорош для композиции и повторного использования чистых трансформаций; процедурный проще, но менее структурирован.
- Тестируемость: функциональный выгоднее (чистые функции); ООП — хорош при правильной инъекции зависимостей; процедурный хуже при большом количестве глобальных мутаций.
Практический выбор зависит от требований: если важна скорость разработки и простота — процедурный/ООП; если важны предсказуемость, параллелизм и лёгкость тестирования — функциональный.