Кратко — когда что удобнее

Процедурное $императивное$ программирование предпочтительно, когда задача простая, линейная, ориентирована на пошаговые инструкции или низкоуровневую реализацию:

Скрипты автоматизации, shell-утилиты, быстрая обработка файлов, конфигурационные установки.Системное/встроенное ПО на C $микроконтроллеры,драйверы$ — где важен контроль над памятью, производительностью и предсказуемость.Сложные численные расчёты со "горячими" внутренними циклами, где нужно минимизировать накладные расходы.

Объектно-ориентированное $OOP$ хорошо, когда нужно моделировать богатую предметную область:

GUI, игры, большие бизнес-приложения, где есть множество сущностей с состоянием и поведением $инкапсуляция,наследование,полиморфизм$.Проекты, где важна расширяемость компонентов и явные интерфейсы/контракты.

Функциональное $FP$ превосходит оба в задачах, где важны:

Безопасность при параллелизме/конкурентности $минимумизменяемогосостояния$.Композиция преобразований данных $конвейеры,map/reduce,трансформацииколлекций$.Вычисления вроде компиляторов, обработки потоков данных/реактивного программирования, трансформаций AST, математическое моделирование.Большие data pipelines и MapReduce-стилe: чистые функции легко распараллелить/кэшировать/тестировать.

Примеры:

Процедурное: bash-скрипт для бэкапа, C-функции для Fast FFT.OOP: видеоигра с иерархией Entity/Player/NPC, расширяемыми поведениями.FP: трансформации потоков событий в реактивной системе, лямбда-выражения для MapReduce, компилятор $построение/преобразованиеAST$.

Теперь — конкретный короткий сценарий: "обработка потоковых данных датчиков — фильтрация некорректных событий, нормализация значений, вычисление скользящей статистики и генерация оповещений, если статистика превышает порог". Покажу реализацию в стиле OOP и в стиле функциональном $Python$. Объясню плюсы/минусы каждого.

1) OOP-стиль $Python—классы,состояниевнутриобъектов$

from collections import deque
class SensorEvent:
def __init__$self,ts,value$:
self.ts = ts
self.value = value
class SlidingStats:
def __init__$self,windo{w}_{s}ize$:
self.window = deque$maxlen=windo{w}_{s}ize$
def add$self,v$:
self.window.append$v$
def mean$self$:
if not self.window:
return None
return sum$self.window$ / len$self.window$
class StreamProcessor:
def __init__$self,windo{w}_{s}ize,threshold$:
self.stats = SlidingStats$windo{w}_{s}ize$ self.threshold = threshold
def validate$self,event$:
# бизнес-логика в методе — может использовать состояние
return event is not None and isinstance$event.value,(int,float)$
def normalize$self,v$:
# пример нормализации: приведение к $$0,1$$ по заранее известному диапазону
MIN, MAX = 0.0, 100.0
return max$0.0,min(1.0,(v-MIN)/(MAX-MIN))$
def process_event$self,event$:
if not self.validate$event$:
return None
v = self.normalize$event.value$ self.stats.add$v$ avg = self.stats.mean if avg is not None and avg > self.threshold:
self.alert$event,avg$ return avg
def alert$self,event,avg$:
# побочный эффект: отправка оповещения
print$f"ALERTatevent.ts:avg=avg:.3f"$
# Использование:
proc = StreamProcessor$windo{w}_{s}ize=5,threshold=0.8$ for ev in incoming_stream: # incoming_stream — генератор событий
proc.process_event$ev$

Плюсы OOP-версии:

Явная инкапсуляция состояния $SlidingStats$, легко хранить различные конфигурации $несколькопроцессоровсразнымиокнами/порогами$.Удобно расширять: наследовать StreamProcessor, переопределить normalize/validate/alert.Код близок к предметной модели — легче понять кто что делает.

Минусы:

Состояние внутри объектов делает тестирование сложнее $нужносбрасывать/инициализироватьсостояние$.Параллельность сложнее: совместный доступ к объектам требует защиты $блокировки$.При большом количестве мелких шагов может возникнуть много небольших классов и методов — перегрузка архитектуры.

2) Функциональный стиль (Python — чистые функции, композиция, минимум мутаций; только "края" делают IO)

from collections import deque
from functools import reduce
import itertools
# событие — обычный кортеж $ts,value$ # валидатор — чистая функция
def validate$event$:
ts, v = event
return v is not None and isinstance$v,(int,float)$
def normalize$v,MIN=0.0,MAX=100.0$:
return max$0.0,min(1.0,(v-MIN)/(MAX-MIN))$
# scan: чистая реализация, возвращающая поток состояний $foldthatyields$ def scan$func,init,iterable$:
state = init
for item in iterable:
state = func$state,item$ yield state
# update stats: state = $deque,maybecachedmean$ — но будем хранить кортеж imm-подходом: new deque $копия$ def sliding_update$windo{w}_{s}ize$:
# возвращает функцию state_update$state,value$ -> new_state
def update$state,value$:
# state: a tuple of $dequ{e}_o{f}_{v}alues$ old_deque = state
d = deque$ol{d}_{d}eque,maxlen=windo{w}_{s}ize$ # создаём новую очередь на основе старой $немутируемвнешний$ d.append$value$ # сохраняем как tuple чтобы намеренно показывать иммутабельность на уровне API
return tuple$d$ return update
def mean_from_state$state$:
d = list$state$ return $sum(d)/len(d)$ if d else None
# конвейер: генераторы + чистые функции
def pipeline$events,windo{w}_{s}ize,threshold$:
# фильтрация
valid = $eforeineventsifvalidate(e)$ # нормализация
normalized = $normalize(e[1])foreinvalid$ # сканируем состояния скользящего окна
update = sliding_update$windo{w}_{s}ize$ states = scan$update,tuple(),normalized$ # каждое state — tuple of recent values
# вычисляем mean и фильтруем по порогу
for state in states:
avg = mean_from_state$state$ if avg is not None and avg > threshold:
yield ${}^{\prime }aler{t}^{\prime },avg$ else:
yield ${}^{\prime }o{k}^{\prime },avg$
# Внешняя часть делает вывод/сайд-эффекты
for status, avg in pipeline$incomin{g}_{s}tream(),windo{w}_{s}ize=5,threshold=0.8$:
if status == 'alert':
print$"ALERT:",avg$

Плюсы функционального варианта:

Ядро $validate,normalize,scan$ — чистые функции, легко тестировать единично.Легче распараллеливать/мемоизировать этапы $безпобочныхэффектов$.Код легче анализируется формально, меньше скрытых состояний.Композиция $generatorpipeline$ очень удобна для потоков.

Минусы:

"Чистая" функциональность в императивном языке $Python$ достигается соглашением — не принуждается на уровне языка.Иногда приходится копировать структуры $впримереdequeкопируется$ — возможен оверхед по памяти/времени; в реальной FP используют специализированные persistent структуры $Clojure,Haskell$.Сложные сценарии с мутацией и побочными эффектами $сеть,база$ требуют аккуратного отделения границ $IO$, что усложняет дизайн.Настоящая "чистота" уменьшает удобство прямой работы с глобальным состоянием; иногда это добавляет лишний код на поддержание явного состояния.

Замечания о «чистой функциональности»:

В чистом FP-языке $Haskell$ аналогичный pipeline будет естественно чистым и безопасным, с выражением состояний через монады $State,IO$ и ленивыми потоками.В производственных потоковых системах часто используют гибрид: функциональные трансформации $map/filter/scan$ в ядре, OOP/императивный код для взаимодействия с внешним миром и ресурсами.

Резюме / рекомендации:

Если задача — линейный скрипт, маленький инструмент или требует максимального контроля над ресурсами — процедурный/императивный стиль.Если задача — моделирование сложной предметной области с множеством взаимосвязанных сущностей — OOP.Если задача — трансформации данных, потоковая обработка, параллельная дедупликация/агрегация/композиция — функциональный стиль $илиязык$ обычно даёт лучшие свойства для поддержки, тестирования и параллелизма.На практике чаще всего используют гибрид: OOP для архитектуры/модулей, FP-подходы внутри модулей для чистых преобразований данных.