Ниже — четыре короткие реализации операции «перевести сумму со счёта A на счёт B» в разных стилях (псевдокод) и краткий разбор по читаемости, тестируемости и безопасности при конкурентных транзакциях.

1) Процедурный стиль
Пример (псевдокод):

function transfer(fromId, toId, amount):
fromBalance = db.readBalance(fromId)
if fromBalance < amount:
return Error("Insufficient funds")
db.beginTransaction()
try:
db.updateBalance(fromId, fromBalance - amount)
toBalance = db.readBalance(toId)
db.updateBalance(toId, toBalance + amount)
db.commit()
return Ok
except:
db.rollback()
return Error("Failed")

Плюсы:

Очень простая и понятная последовательность действий.Легко понять и отладить шаги.

Минусы:

Чистая реализация чувствительна к конкурентному доступу: нужны транзакции или блокировки на уровне БД/приложения.Тестирование требует мока БД или тестовой БД; чистота кода ниже, т.к. много побочных эффектов.Лёгко допустить ошибки (например, чтение вне транзакции, дедлоки при некорректном порядке блокировок).

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

class Account:
id
balance
mutex
method debit(amount):
if balance < amount: raise Error
balance -= amount
method credit(amount):
balance += amount
function transfer(from: Account, to: Account, amount):
// Блокируем в порядке id, чтобы избежать дедлока
lock( min(from.id,to.id).mutex )
lock( max(from.id,to.id).mutex )
try:
from.debit(amount)
to.credit(amount)
finally:
unlock both

Плюсы:

Инкапсуляция операций над аккаунтом (debit/credit), ясные абстракции.Легче мокать объекты и юнит-тестировать методы класса.Можно локализовать логику синхронизации внутри класса/сервиса.

Минусы:

Требуется аккуратная организация блокировок (порядок блокировки) чтобы избежать дедлоков.Если есть распределённая БД, локи на приложении не помогут — нужен механизм транзакций на уровне БД.Модель с мутируемыми объектами усложняет reasoning при высокой конкуренции.

3) Функциональный стиль (чистые функции, неизменяемость)
Пример (функция возвращает новый «стейт»):

function transfer(state, fromId, toId, amount):
fromBal = state.accounts[fromId]
if fromBal < amount: return Error("Insufficient")
newAccounts = state.accounts
.set(fromId, fromBal - amount)
.set(toId, state.accounts[toId] + amount)
return Ok(new State(accounts = newAccounts))

Плюсы:

Чистая, детерминированная функция без побочных эффектов => очень легко юнит-тестировать.Обновление состояния возвращает новый объект — избегаем частых гонок в памяти внутри функции.Хорошо сочетается с моделями безопасной конкурентности (STM, immutable data + CAS, акторы).

Минусы:

В реальной системе нужно согласовать публикацию/персистентность нового состояния (например, атомарное записывание в БД), иначе возникают гонки.При больших состояниях копирование может быть дорого; нужны структуры «персистентных» данных.Порог вхождения выше для команд, не привыкших к FP-стилю.

4) Логический стиль (Prolog-подобный)
Пример (декларативное правило; реализация изменений зависит от движка):

% Факты: balance(Id, Amount).
% Правило (декларативно описывает возможный переход):
transfer(From, To, A) :-
balance(From, BF), BF >= A,
BF2 is BF - A,
balance(To, BT),
BT2 is BT + A,
retract(balance(From, BF)),
retract(balance(To, BT)),
assert(balance(From, BF2)),
assert(balance(To, BT2)).

Плюсы:

Декларативное описание свойств и условий облегчает формальное мышление и верификацию правил.Правила хорошо подходят для выражения бизнес-логики (условия, валидации).

Минусы:

В Prolog-стиле факты и assert/retract — это побочные эффекты; обновление состояния становится императивным и часто плохо масштабируется.Поведение при конкуренции зависит от конкретной реализации логической БД; часто нет встроенной поддержки атомарных транзакций, поэтому нужно внешнее блокирование/ТХ.Менее привычно для многих разработчиков, тесты и моки могут быть сложнее организовать (или зависят от движка).

Краткое сравнение по трём критериям

Читаемость

Процедурный: очень нагляден для большинства — шаги последовательны.OOP: понятен, если модель домена выражена в классах; буквы понятны архитекторам.Функциональный: очень ясен логически, но требует понимания неизменяемости.Логический: декларативен, но непривычен для многих; правила читаются как логика, а не как шаги.

Тестируемость

Функциональный: лучший (чистые функции легко юнит-тестировать).OOP: хорошая (моки, инъекция зависимостей).Процедурный: приемлемо, но зависит от мока/тестовой БД.Логический: средне; тестируемость зависит от средств запуска/изоляции фактов.

Безопасность при конкурентных транзакциях

Процедурный: нужно явное использование транзакций/локов; без них — уязвим.OOP: можно встроить локи/синхронизацию в методы; риск дедлоков без правил порядка.Функциональный: внутри функции безопасно, но интеграция с общей БД требует CAS/STM/транзакций; при правильной интеграции — очень хорош.Логический: сам по себе не гарантирует атомарности; нужен движок с транзакциями или внешняя синхронизация.

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

Для реальных банковских переводов опирайтесь на надёжный механизм атомарности: транзакции на уровне СУБД (ACID) или распределённые транзакции/идемпотентные операции и проверенные модели (reservation/commit, оплата через очередь событий).Для простоты разработки и тестов: используйте чистые функции для бизнес-логики (валидация и вычисление итогов) + слой инфраструктуры (транзакции/БД) для выполнения побочных эффектов.При многопоточной работе согласуйте порядок блокировок или используйте оптимистичную стратегию с повтором (CAS) или STM, чтобы избежать дедлоков.

Если хотите, могу привести реализацию каждого стиля для конкретного языка (например, Python/Java/Elixir/Prolog) или показать, как безопасно интегрировать функциональную бизнес-логику с транзакционной БД.