Ниже — компактное сравнение реализации паттерна «наблюдатель» в трёх парадигмах с короткими псевдокодами и оценкой по масштабированию, отладке и согласованности состояния.

1) Императивное OOP (пример в стиле Java)
Псевдокод

интерфейс наблюдателя:
interface Observer { void update(Event e); }субъект:
class Subject {
private final List observers = new ArrayList<>();
synchronized void subscribe(Observer o) { observers.add(o); }
synchronized void unsubscribe(Observer o) { observers.remove(o); }
void notify(Event e) {
// синхронизированное чтение, вызовы могут выполняться в потоке субъекта
List snapshot;
synchronized(this) { snapshot = new ArrayList<>(observers); }
for (Observer o : snapshot) {
o.update(e); // или submit в ExecutorService для асинхронности
}
}
}

Плюсы

Простота и прямой контроль (когда кто и в каком потоке вызывается).Легко использовать отладчик, видеть стек вызовов и изменяемые поля.Подходит для компактного локального взаимодействия.

Ограничения при масштабировании

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

Отладка

Сильные средства отладки (стек, точки останова), но гонки/deadlock трудно воспроизвести.Распараллеливание усложняет трассировку.

Согласованность состояния

Общий мутируемый стейт требует синхронизации. Ошибки синхронизации приводят к рассинхронизации и неконсистентным состояниям.Можно добиваться строгой согласованности через блокировки, но ценой производительности и риска deadlock.

2) Функциональный стиль — Elixir (актеры) и Haskell (чистая/STM/FRP)
a) Elixir (процессы/GenServer/pubsub)
Псевдокод

GenServer держит state и список подписчиков (pid):
handle_call {:subscribe, pid}, _from, state -> {:reply, :ok, state |> add(pid)}
handle_cast {:notify, event}, state ->
for pid <- state.subscribers do send(pid, {:event, event}) end
{:noreply, state}

Или использовать PubSub (Phoenix.PubSub) — подписался на topic, публикуешь — PubSub рассылает.

Плюсы

Лёгкие процессы, изоляция ошибок, supervision tree (автоматический ресет).Нет общих мутируемых данных между процессами — упрощает рассуждения.Хорошо масштабируется горизонтально (распределение по узлам).

Ограничения при масштабировании

Согласованность между процессами — eventual/событийная; для сильной согласованности нужны дополнительные механизмы (например, Mnesia, CRDT, распределённый consensus).Нужна архитектура (шардирование топиков, балансировка), если число подписчиков очень велико.

Отладка

Инструменты (observer, tracing). Хорошая изоляция ошибок.Труднее отслеживать межпроцессные гонки/порядок доставки (сообщения асинхронны).

Согласованность состояния

Состояние последовательно внутри одного процесса (детерминировано по сообщениям).Между процессами — асинхронность => eventual consistency; если нужен атомарный апдейт нескольких процессов, используют транзакции/coordination.

b) Haskell (чистая + STM или FRP)
Псевдокод STM
observersVar <- newTVarIO []
subscribe = atomically $ do
chan <- newTChan
modifyTVar observersVar (chan:)
return chan
notify e = atomically $ do
obs <- readTVar observersVar
forM_ obs $ \c -> writeTChan c e

FRP (reactive-banana style)
eventSource <- newEvent
registerHandler eventSource (\e -> / обработчик /)
fireEvent eventSource e

Плюсы

Чистота и отсутствие побочных эффектов (в Haskell) упрощают тестирование и верификацию.STM даёт композиционные атомарные операции — легко гарантировать согласованность локальных транзакций.FRP позволяет выразить сложные временные зависимости декларативно.

Ограничения при масштабировании

Чистый Haskell/FRP выполняется в процессе; для масштабирования нужны распределённые решения.FRP абстракции могут скрывать производительность/память (потенциально расти граф зависимостей).В Elixir распределение естественно; в Haskell надо добавлять сеть/coordination.

Отладка

Функциональные части легко тестировать (меньше mutable state).FRP и ленивость могут затруднять трассировку (сложный граф подписок).STM упрощает отладку конкурентных мутаций по сравнению с низкоуровневыми блокировками.

Согласованность состояния

STM: сильная локальная согласованность (атомарные транзакции).FRP: детерминизм потоков при детерминированных источниках; если источники внешние — нужна стратегия слияния/разрешения конфликтов.Elixir: согласованность внутри процесса гарантирована, между — eventual.

3) Реактивная библиотека — RxJS (Observable/Subject)
Псевдокод
const subject = new Subject();
const subscription = subject
.pipe(
filter(x => condition(x)),
map(x => transform(x))
)
.subscribe({
next: x => handle(x),
error: e => handleError(e)
});
subject.next(event); // рассылка
subscription.unsubscribe(); // обязательно при отписке

Плюсы

Декларативная обработка потоков (операторы трансформации, фильтрации, буферизации).Хорошо выражены композиция, трансформации, управление потоками (throttle, debounce, buffer).Поддерживает асинхронность и ленивость, объединение нескольких источников (merge, combineLatest).

Ограничения при масштабировании

JS обычно однопоточный (в браузере), значит обработка тяжёлых задач блокирует event loop — нужны web workers/Node child processes.Без дополнительных механизмов ограничена поддержка backpressure (в RxJS есть некоторые стратегии, но не так мощно, как в системах с backpressure на уровне транспорта).На больших топиках/сотнях тысяч подписчиков память и GC могут стать узким местом.

Отладка

Комбинация операторов может скрывать стек вызовов; сложные цепочки трудно отлаживать.Инструменты: marble tests, DevTools для Rx (есть), логирование внутри потоков.Асинхронность и отсутствие естественного стека затрудняют трассировку источника события.

Согласованность состояния

Обычно поток → чистые операторы → локальное состояние (например, scan для аккумуляции). Это снижает рассинхронизацию.Совместный мутируемый стейт — источник проблем; лучше держать состояние в потоках (single source of truth).Для гарантированной атомарности нескольких связанных обновлений нужно проектировать поток так, чтобы они шли в одной транзакции/одном событии.

Сравнительная сводка (ключевые аспекты)

Масштабирование

Java OOP: мощно на многопоточной JVM, но сложна синхронизация и управление ресурсами.Elixir: отлично для большого числа лёгких процессов и распределённых систем; требует проектирования согласованности.Haskell: сильна за счёт чистоты и STM; для распределения нужны дополнительные слои.RxJS: хорош для клиентских/серверных реактивных приложений, но ограничен моделью исполнения (однопоточный JS) и требует внешних механизмов для масштабного параллелизма.

Отладка

Java: классический отладчик и стек, но гонки тяжело находить.Elixir: инструменты для наблюдения процессов и supervision; асинхронность усложняет межпроцессные сценарии.Haskell: тестируемость и детерминизм упрощают отладку; FRP/ленивость иногда усложняют.RxJS: декларативные пайпы облегчают логику, но композиция и асинхронность требуют специальных тестов (marble) и логирования.

Согласованность состояния

Java: вручную через синхронизацию — риск ошибок.Elixir: согласованность в границах процесса; распределённое состояние — eventual/нужна дополнительная логика.Haskell: STM/чистые функции дают сильные гарантии локальной согласованности.RxJS: потоковый локальный state (scan) безопаснее, чем глобальные мутабельные объекты; атомарные мульти-обновления требуют особой архитектуры.

Рекомендации при выборе

Если нужна простая локальная публика-подписка в монолитном приложении — OOP/Java приемлема.Для высоконагруженных распределённых систем с требованием устойчивости — Elixir/OTP (актерная модель).Для систем, где хочется формально управлять конкурентностью и транзакциями — Haskell + STM/FRP.Для UI/клиентских реактивных потоков и декларативной трансформации событий — RxJS (или Rx в других языках), с вниманием на отписку и backpressure.

Если хотите, могу:

показать конкретные примеры кода для Java/Elixir/Haskell/RxJS (реальные, а не псевдокод),или сравнить производительность/потребление памяти для типичных сценариев (публикация тысячи событий/сек).