Кратко: сравнение трёх парадигм на примере реализации калькулятора выражений (например, парсинг/представление/eval для выражения типа $1+2\ast 3$) по трём критериям: расширяемость, тестируемость, производительность.
1) Процедурная (императивная)
- Как обычно реализуется: парсер строит структуру или сразу вычисляет с помощью процедур/функций и большого `switch`/`if` по типу токена/оператора; состояние и результаты передаются или хранятся в глобальных/локальных переменных.
- Расширяемость:
- Плюсы: просто добавить новую операцию, если архитектура монолитна — изменить центральную функцию обработки.
- Минусы: нарушается принцип открытости/закрытости — изменения часто затрагивают один большой метод; сложнее добавить новые трансформации (оптимизации, типизацию) без модификации существующего кода.
- Тестируемость:
- Плюсы: простые функции легко юнит-тестировать; поведение линейно и предсказуемо.
- Минусы: если используется много глобального состояния или побочных эффектов, тесты сложнее изолировать.
- Производительность:
- Плюсы: обычно самое быстрое исполнение — прямой код, минимальные аллокации/абстракции.
- Минусы: масштабируемость и повторное использование кода хуже, что может вести к дублированию и ошибкам.
2) Объектно-ориентированная
- Как: выражение — иерархия классов (например, BinaryOp, Number, Variable) с методом `eval()`; или AST + visitor для отдельных проходов.
- Расширяемость:
- Плюсы: легко добавлять новые виды узлов (новые операторы) — добавляется новый класс; код соответствует принципу единственной ответственности.
- Минусы: добавить новую операцию над всеми узлами (новый проход — например, сериализация, оптимизация) без visitor сложно (нужны изменения в каждом классе) — классическая «проблема расширения по операциям vs по типам данных».
- Тестируемость:
- Плюсы: хорошая модульность — каждый класс можно тестировать отдельно; совпадение состояния и поведения инкапсулировано.
- Минусы: может потребоваться мокать/инжектить зависимости (контексты выполнения), тесты на поведение через полиморфизм иногда сложнее понять.
- Производительность:
- Минусы: накладные расходы на аллокации объектов, виртуальные вызовы методов; больший объём кода/памяти.
- Плюсы: при необходимости можно оптимизировать узлы (пулинг, flyweight) или применять visitor для одной быстрой итерации.
3) Функциональная
- Как: выражения — иммутабельные ADT (алгебраические типы), вычисление — чистая рекурсивная функция `eval(expr, env)`; широко применяются композиция, высшие функции, pattern matching.
- Расширяемость:
- Плюсы: чистые функции и композиции упрощают добавление новых трансформаций (комбинаторы, оптимизации как отдельные чистые функции); в языках с алгебраическими типами и typeclasses возможны «открытые» расширения (через суммирование эффектов, модули).
- Минусы: добавление новых типов узлов часто требует изменения pattern matching в многих функциях (как в процедурном/функциональном стиле), если не использовать экстенсивные паттерны проектирования.
- Тестируемость:
- Плюсы: отличная тестируемость: чистые функции, отсутствие побочных эффектов, легко использовать property-based тесты; проще композиционно тестировать отдельные трансформации.
- Минусы: иногда требуется больше фикстур для имитации контекста (но это проще, чем мок объектов).
- Производительность:
- Минусы: возможны частые аллокации (новые структуры, замыкания), рекурсия может требовать оптимизаций (tail-call, обмен в стек), но компиляторы/оптимизаторы (инлайнинг, fusion) часто компенсируют.
- Плюсы: благодаря оптимизациям (ленивость, fusion, константное сворачивание) можно получить очень эффективные реализации; легко писать параллельные/ленивые/потоковые вычисления.
Резюме/рекомендации (кратко)
- Нужен простой, быстрый калькулятор с минимальной архитектурой — процедурный подход: максимум производительности и простоты, но хуже масштабируемость.
- Нужна богатая иерархия выражений, объект-ориентированное API и инкапсуляция поведения — OOP: хороша при росте набора типов узлов, удобна для IDE/DSL, но более тяжёлая по памяти и вызовам.
- Нужны корректность, лёгкость тестирования, композиция трансформаций и лёгкая параллелизация — функциональный подход: лучше для сложных трансформаций и формальных доказательств, иногда требует оптимизаций ради производительности.
Если хотите, могу кратко показать иллюстративный псевдокод для каждого подхода.