Кратко и по пунктам — как меняются модель данных, управление состоянием, тестируемость и расширяемаемость при решении одной и той же задачи (площадь сложной фигуры с вложенными примитивами) в стиле C, Java, Haskell и Prolog.
1) Процедурный стиль (C)
- Модель данных: структуры и теги (enum + union) — дерево узлов вида {type, данные, массив детей}. Поля вручную выделяются/освобождаются.
- Управление состоянием: императивно, мутабельные структуры; трансформации часто делают in-place; явное управление памятью.
- Тестируемость: возможны модульные тесты для чистых функций (например, area(node)), но в реальности код часто смешивает I/O и управление памятью — тестирование сложнее; ошибки памяти и UB.
- Расширяемость:
- добавить новый примитив → нужно изменить switch/if-цепочки во всех функциях, которые по типу разбирают узел (плохая поддержка открытого расширения по типам);
- добавить новую операцию (новая функция, напр. render) → легко: написать новую функцию, обходящую дерево.
- Подход к вычислению площади: рекурсивный обход дерева, вычисления по формулам, например круг $\pi r^2$, прямоугольник $lw$, многоугольник — шузласовская формула $\frac{1}{2}\left|\sum (x_i{y}_{i+1}-x_{i+1}{y}_i)\right|$.
2) Объектно‑ориентированный стиль (Java)
- Модель данных: иерархия классов/интерфейсов: интерфейс Shape { double area(); } классы Circle, Rectangle, Composite и т.д. Composite pattern для вложенности.
- Управление состоянием: объекты могут быть мутабельными или неизменяемыми; чистые методы дают простое тестирование; состояние чаще скрыто (инкапсуляция).
- Тестируемость: хорошая (JUnit, мок-объекты). Полиморфизм упрощает подмену реализаций в тестах.
- Расширяемость:
- добавить новый примитив → легко: создать новый класс, реализующий Shape (не меняя существующий код);
- добавить новую операцию (новый алгоритм над всеми видами) → либо добавлять метод в интерфейс (ломает реализаций) либо использовать Visitor (сложнее), т.е. классический trade‑off выражения проблемы (expression problem).
- Подход к вычислению площади: виртуальные методы area(), композиция; для булевых операций над областями (union/diff) используют паттерны (Composite, Strategy) или специализированные библиотеки.
3) Функциональный стиль (Haskell)
- Модель данных: алгебраические типы данных (ADT): data Shape = Circle Double | Rect Double Double | Composite [Shape] | Union Shape Shape | ... — дерево выражений.
- Управление состоянием: неизменяемость; вычисления — чистые функции; трансформации возвращают новые значения (без побочных эффектов).
- Тестируемость: отличная — чистые функции легко юнитить и свойственно property‑based testing (QuickCheck). Референциальная прозрачность упрощает отладку и дедукцию.
- Расширяемость:
- добавить новую операцию → очень просто: написать новую функцию area :: Shape -> Double (pattern matching);
- добавить новый примитив → нужно изменить ADT и обновить все функции, делающие pattern matching (т.е. ADT удобно расширять по операциям, менее удобно — по вариантам; классическая сторона expression problem).
- Подход к вычислению площади: рекурсия/свёртки (fold). Формулы те же: круг $\pi r^2$, прямоугольник $lw$. Для булевых комбинаций часто применяют функциональные алгоритмы/библиотеки, либо численную интеграцию/триангуляцию.
4) Логический стиль (Prolog)
- Модель данных: термы и факты: circle(Id, R). composite(union, A, B) или shape(tree(...)). Геометрия представлена как декларативные правила.
- Управление состоянием: декларативный, без явной мутации; вычисление через унификацию и правила; можно использовать динамическую базу (assert/retract) при необходимости состояния, но это побочный эффект.
- Тестируемость: возможно (юнит‑фреймворки для Prolog), удобно тестировать логические свойства и запросы; непредсказуемый порядок поиска и бэктрекинг усложняют тесты, если есть неограниченная недетерминированность.
- Расширяемость:
- добавить новый примитив → добавить новый клауза/правило для предиката area/2 (очень просто);
- добавить новую операцию → определить новый предикат (также просто). Prolog гибок для добавления и того, и другого, но модульность/контроль пересечений правил требует заботы.
- Подход к вычислению площади: правила вида
area(circle(R), A) :- A is pi*R*R.
area(union(A,B), S) :- area(A,SA), area(B,SB), /* учесть пересечение */ ...
Учёт пересечений/разностей может требовать вычислительной геометрии или численного/символьного решения — в Prolog это декларативно формулируется, но реализация часто обращается к библиотекам/алгоритмам.
Сравнительная сводка (коротко)
- Модель данных:
- C: структурные теги + ручное управление; код разбора типов централизован (switch).
- Java: объекты с поведением (полиморфизм).
- Haskell: выражения/ADT и pattern matching.
- Prolog: термы и правила.
- Управление состоянием:
- C/Java: допускается мутация (Java даёт инкапсуляцию), C — низкоуровневая.
- Haskell: неизменяемость и чистота.
- Prolog: декларативность, без явной мутации (кроме динамических фактов).
- Тестируемость:
- Лучше всего в Haskell (чистота, QuickCheck) и Java (инструменты, mocks).
- C — тяжелее из‑за утечек памяти и смешения обязанностей.
- Prolog — хорош для логических свойств, сложнее при побочных эффектах/недетерминированности.
- Расширяемость (expression problem):
- OOP/Java: легко добавить новые типы (классы), сложнее новые операции без шаблонов (Visitor).
- ADT/Haskell/C (switch): легко добавить новые операции (функции), сложнее новые варианты типов.
- Prolog: гибко добавлять и то, и другое (новые клаузы/предикаты), но контроль пересечений/совместимости — на разработчике.
Вывод (одно предложение): выбор парадигмы влияет на то, как вы моделируете фигуру (структуры/объекты/термы/ADT), кто отвечает за мутацию и где лежит логика вычисления площади; Haskell и Java дают чистые, хорошо тестируемые подходы (каждый со своими преимуществами в расширяемости), C даёт контроль и эффективность ценой сложности, Prolog — удобен для декларативного/символьного описания правил, но менее прямолинеен для численной геометрии.