Коротко и по делу — для одной и той же задачи «банковский счёт с историей операций» — дизайн и сравнение в трёх стилях. Формулы/подписи функций — в KaTeX.

1) Процедурный стиль

Дизайн: глобальное / модульное состояние и функции, которые его мутируют. Пример концептуально:
состояние: $\text{balance}$ и $\text{history}=[\dots ]$функции: $\text{init}()$, $\text{deposit}(\text{amount})$ — меняют $\text{balance}$ и добавляют запись в $\text{history}$.операция: $\text{deposit}(\text{amount}):\text{balance}=\text{balance}+\text{amount};\text{history}.append(\text{record})$Плюсы:
простота и низкий порог вхождения;прямой контроль над изменениями состояния.Минусы:
побочные эффекты распределены по коду → сложнее локализовать и тестировать unit-тестами;проблемы с параллелизмом (нужна синхронизация);масштабирование коду с ростом требований ведёт к запутанности (спагетти-состояние).Тестируемость/масштабируемость/сопровождение:
тестируемость: интеграционные тесты просты, unit-тесты требуют подстановки/сброса глобального состояния;масштабируемость: хуже при многопоточности и распределённых подсистемах;сопровождение: рост техдолга при увеличении числа точек изменения состояния.

2) Объектно-ориентированный стиль

Дизайн: класс Account инкапсулирует состояние и методы. Пример:
класс Account { $\text{balance}$, $\text{history}$; методы $\text{deposit}(\text{amount})$, $\text{withdraw}(\text{amount})$ }метод: $\text{deposit}(\text{amount}):this.balance+=\text{amount};this.history.push(\text{record})$можно добавить интерфейсы, абстракции (IAccount), зависимости (репозиторий, логирование) через DI.Плюсы:
инкапсуляция состояния — точка контроля изменений;легко моделировать разные поведения через наследование/композицию;удобнее мокать/подставлять зависимости для тестов (интерфейсы).Минусы:
мутируемая внутренняя модель всё ещё содержит побочные эффекты — сложность при параллельности;неправильное использование наследования приводит к хрупкой архитектуре;состояние скрыто — менее прозрачно для анализа (нужны контрактные тесты).Тестируемость/масштабируемость/сопровождение:
тестируемость: хорошие возможности unit-тестов через мокирование; легче писать интеграционные тесты;масштабируемость: объекты естественно распределяются, но при высокой конкуренции нужен синхронный доступ или акторная модель;сопровождение: при хорошей архитектуре (интерфейсы, SRP) — хорошая поддерживаемость; при «богатых» объектах — сложнее.

3) Функциональный стиль

Дизайн: состояние не мутирует; операции — чистые функции, возвращающие новое состояние; побочные эффекты изолируются (ex: IO-монанда, эффекты явно прокидываются). Пример:
состояние: $\text{AccountState}=\{\text{balance},\text{history}\}$функция: $\text{deposit}(\text{state},\text{amount})\to \text{newState}$, где $\text{newState}=\{\text{balance}=\text{state.balance}+\text{amount},\text{history}=\text{state.history}++[\text{record}]\}$побочные эффекты (постоянство/логирование/IO) выполняются отдельно: $\text{persist}(\text{state})$ или собираются в список действий.Плюсы:
чистые функции — лёгкая модульность и отличная unit-тестируемость (реферальная прозрачность);безопасность в параллельной и распределённой среде (иммутабельность);ясная трассировка изменений состояния (удобно для отладки, историй, event-sourcing).Минусы:
возможные накладные расходы на копирование данных (решается структурной/профессиональной иммутабельностью);сложность интеграции с внешним императивным IO — требуется явная обработка эффектов (монады/эффектные системы), что повышает порог вхождения;сложнее выразить некоторые инварианты, которые удобно поддерживать через инкапсуляцию в OOP.Тестируемость/масштабируемость/сопровождение:
тестируемость: отличная — функции легко тестировать в изоляции;масштабируемость: очень хорошая для параллелизма и горизонтального масштабирования; легко делать репликацию состояний и event-log;сопровождение: при дисциплине (разделение чистоты и эффектов) код проще понимать и рефакторить; но требует дисциплины и знаний.

Короткое сравнение по направлениям (сравнительно)

Локализация побочных эффектов: FP > OOP > процедурный.Простота понимания (для начинающих): процедурный ≈ OOP > FP.Параллельность и масштабируемость: FP > OOP > процедурный.Unit-тестируемость: FP ≈ OOP (при DI) > процедурный.Сопровождение в крупной системе: OOP или FP при правильной архитектуре лучше, процедурный — чаще хуже.

Рекомендация практическая

Небольшая однофайловая утилита — процедурный или простой OOP.Система с конкуренцией/распределением/жёсткой корректностью — функциональный подход или event-sourcing (иммутабельный лог транзакций).Большой продукт с командами — OOP с явной инъекцией зависимостей или гибрид FP (чистые ядра + императивный слой для IO).

Если нужно, могу привести минимальные псевдокоды (пример реализации) для каждого стиля.