Почему в монолитных сервисах не используется функциональный подход?

Краткий ответ

Аргумент в вопросе неточный. На самом деле функциональный подход используется в монолитных сервисах, особенно в Python. Однако есть причины, почему объектно-ориентированный подход предпочтителен в больших монолитах: управление состоянием, инкапсуляция, повторное использование, паттерны проектирования и интеграция с фреймворками.

Функциональный подход: суть

Функциональное программирование основано на:

• Чистых функциях (без побочных эффектов)
• Неизменяемых данных (immutability)
• Функциях высшего порядка (higher-order functions)
• Композиции функций

# Функциональный подход
from typing import Callable, List
from functools import reduce

def add(a: int, b: int) -> int:
    return a + b

def multiply(a: int, b: int) -> int:
    return a * b

def compose(f: Callable, g: Callable) -> Callable:
    """Композиция функций"""
    return lambda x: f(g(x))

def apply_functions(data: List[int], operations: List[Callable]) -> List[int]:
    """Применить набор операций к данным"""
    return [reduce(lambda x, op: op(x), operations, item) for item in data]

# Использование
result = apply_functions([1, 2, 3], [lambda x: x * 2, lambda x: x + 1])
# Result: [3, 5, 7]

Объектно-ориентированный подход: суть

ОО программирование основано на:

• Классах и объектах
• Инкапсуляции состояния
• Наследовании и полиморфизме
• SOLID принципах

# ОО подход
class User:
    def __init__(self, id: int, name: str, email: str):
        self._id = id
        self._name = name
        self._email = email
    
    @property
    def id(self) -> int:
        return self._id
    
    @property
    def name(self) -> str:
        return self._name
    
    def update_email(self, new_email: str):
        if self._is_valid_email(new_email):
            self._email = new_email
        else:
            raise ValueError('Invalid email')
    
    def _is_valid_email(self, email: str) -> bool:
        return '@' in email and '.' in email

# Использование
user = User(1, 'John', 'john@example.com')
user.update_email('john.doe@example.com')

Почему OO подход в монолитах?

Причина 1: Управление состоянием

Монолиты обрабатывают множество взаимосвязанных сущностей с состоянием:

# Функциональный подход - сложно
def process_user_and_posts(user_id):
    user = get_user(user_id)
    posts = get_posts(user_id)
    comments = get_comments(posts)
    
    user = update_user_stats(user, posts, comments)
    user = calculate_permissions(user, posts)
    user = apply_filters(user, comments)
    
    return user  # Нужно передавать estado везде

# ОО подход - естественнее
class UserService:
    def __init__(self):
        self.db = Database()
        self.cache = Cache()
    
    def get_user_profile(self, user_id):
        user = User(self.db.fetch(user_id))
        user.load_posts()  # Состояние инкапсулировано
        user.load_comments()
        user.calculate_stats()  # Метод знает о состоянии
        return user.to_dict()

Причина 2: Инкапсуляция

В большом монолите сложная логика нужно скрывать:

# Функциональный - всё открыто
def create_payment(user_data, cart_data, discount_data):
    amount = calculate_total(cart_data)
    amount = apply_discount(amount, discount_data)
    amount = apply_tax(amount, user_data['country'])
    
    transaction = initiate_transaction(amount, user_data['card'])
    log_transaction(transaction, user_data, cart_data)
    send_email(user_data['email'], transaction)
    update_inventory(cart_data)
    
    return transaction

# ОО подход - логика скрыта
class PaymentProcessor:
    def __init__(self, user: User, cart: Cart):
        self.user = user
        self.cart = cart
        self.logger = Logger()
        self.email_service = EmailService()
        self.inventory = Inventory()
    
    def process(self) -> Payment:
        # Клиент не знает о внутренних деталях
        amount = self._calculate_total()
        transaction = self._create_transaction(amount)
        self._finalize(transaction)
        return transaction
    
    def _calculate_total(self) -> float:
        """Приватный метод - логика скрыта"""
        # Сложные вычисления
        pass
    
    def _create_transaction(self, amount: float):
        # Сложная инициализация
        pass
    
    def _finalize(self, transaction):
        # Логирование, письма, инвентарь
        pass

Причина 3: Переиспользование кода

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

# Функциональный подход
def log_user_created(user_data):
    log(f'User created: {user_data["name"]}')

def log_user_updated(user_data):
    log(f'User updated: {user_data["name"]}')

def log_user_deleted(user_data):
    log(f'User deleted: {user_data["name"]}')

# Много дублирования

# ОО подход
class Entity:
    def __init__(self, name):
        self.name = name
    
    def _log(self, action):
        log(f'{self.__class__.__name__} {action}: {self.name}')

class User(Entity):
    def save(self):
        # Логирование автоматически
        self._log('created')
    
    def update(self):
        self._log('updated')
    
    def delete(self):
        self._log('deleted')

# Логика переиспользуется

Причина 4: Фреймворки требуют OO

Популярные фреймворки для монолитов (Django, Flask, FastAPI) строятся вокруг классов:

# Django - полностью ОО
from django.db import models
from django.views import View

class Post(models.Model):
    title = models.CharField(max_length=200)
    author = models.ForeignKey(User, on_delete=models.CASCADE)

class PostListView(View):
    def get(self, request):
        posts = Post.objects.all()
        return render(request, 'posts/list.html', {'posts': posts})

# FastAPI - можно функциональный
@app.get('/posts')
async def get_posts():
    return db.query(Post).all()

# Но лучше OO
class PostService:
    def get_all(self):
        return db.query(Post).all()

post_service = PostService()

@app.get('/posts')
async def get_posts():
    return post_service.get_all()

Причина 5: SOLID принципы

OO дизайн позволяет следовать SOLID в больших проектах:

# SOLID через OO

# Single Responsibility
class UserRepository:  # Только БД операции
    def save(self, user): pass
    def find_by_id(self, id): pass

class UserValidator:  # Только валидация
    def validate(self, user): pass

class UserService:  # Бизнес-логика
    def __init__(self, repo: UserRepository, validator: UserValidator):
        self.repo = repo
        self.validator = validator
    
    def create(self, data):
        self.validator.validate(data)
        user = User(data)
        self.repo.save(user)

# Open/Closed
class PaymentProcessor:
    def process(self, payment_method: PaymentMethod):
        return payment_method.process()  # Расширяемо

class CreditCard(PaymentMethod):
    def process(self):
        # Реализация для карт
        pass

class PayPal(PaymentMethod):
    def process(self):
        # Реализация для PayPal
        pass

Причина 6: Паттерны проектирования

Монолиты часто используют паттерны, которые требуют OO:

# Dependency Injection
class UserController:
    def __init__(self, user_service: UserService, logger: Logger):
        self.service = user_service
        self.logger = logger

# Repository pattern
class UserRepository:
    def get_by_id(self, id): pass

class CachedUserRepository(UserRepository):
    def __init__(self, db_repo: UserRepository, cache: Redis):
        self.db_repo = db_repo
        self.cache = cache
    
    def get_by_id(self, id):
        cached = self.cache.get(f'user:{id}')
        if cached:
            return cached
        user = self.db_repo.get_by_id(id)
        self.cache.set(f'user:{id}', user)
        return user

# Observer pattern
class UserCreated(Event):
    pass

class UserEventHandler:
    def handle(self, event: UserCreated):
        send_welcome_email(event.user)

Когда функциональный подход уместнее?

# 1. Обработка данных (ETL, трансформации)
def transform_data(raw_data):
    return (raw_data
            .filter(lambda x: x['active'])
            .map(lambda x: {'id': x['id'], 'name': x['name'].upper()})
            .reduce(lambda acc, x: acc + [x], []))

# 2. Конвейеры обработки (pipelines)
def process_pipeline(data, *transformers):
    return reduce(lambda x, f: f(x), transformers, data)

# 3. Функции-утилиты
from functools import lru_cache

@lru_cache(maxsize=128)
def fibonacci(n):
    if n < 2: return n
    return fibonacci(n-1) + fibonacci(n-2)

# 4. Async обработка
async def fetch_multiple_users(ids):
    tasks = [fetch_user(id) for id in ids]
    return await asyncio.gather(*tasks)

Гибридный подход (рекомендуется)

Современные монолиты используют оба подхода:

class OrderService:  # OO для структуры
    def __init__(self, repo: OrderRepository):
        self.repo = repo
    
    def create_order(self, items, discounts):
        # Функциональный для обработки данных
        total = self._calculate_total(items)
        discounted = self._apply_discounts(total, discounts)
        
        order = Order(items, discounted)
        self.repo.save(order)
        return order
    
    @staticmethod
    def _calculate_total(items):
        # Чистая функция
        return sum(item['price'] * item['qty'] for item in items)
    
    @staticmethod
    def _apply_discounts(total, discounts):
        # Функциональная композиция
        return reduce(
            lambda amount, discount: amount * (1 - discount['percent']/100),
            discounts,
            total
        )

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