Проше — кратко по каждому подходу: что за структуры данных, как контролируется состояние, как распределяются обязанности; плюс короткая подсказка реализации.
1) Процедурное (императивное)
- Структуры данных: простые контейнеры — массив/список или словарь/хэш таблица пользователей: запись {username, password_hash, roles, last_login, ...}. Таблица сессий (session_id → username, expiry).
- Контроль состояния: глобальные или передаваемые по ссылке mutable структуры; операции напрямую модифицируют (insert/update/delete). Смысл — команды (функции) явно меняют состояние.
- Распределение ответственности: набор функций: init_db(), register_user(), authenticate(), create_session(), logout(), check_permission(). Логика аутентификации сосредоточена в этих процедурах; валидация и хэширование пароля — отдельные утилитарные функции.
- Пример/заметка: authenticate(username, password, users_table, sessions_table) — функция проверяет, обновляет таблицы и возвращает session_id. Хорошо для небольших скриптов, легко читать, но сложнее при росте и конкуренции.
2) Объектно-ориентированное
- Структуры данных: классы/объекты: User {username, password_hash, roles}, Session {id, user, expiry}, AuthService {user_store, session_store, methods…}. Внутри store может быть репозиторий/DAO.
- Контроль состояния: состояние инкапсулировано в объектах; методы меняют состояние объекта. Мьютируемые поля классов; можно использовать паттерны (Singleton для session manager, Repository, Service).
- Распределение ответственности: объекты отвечают за свои данные и поведение: User — за валидацию/соль; AuthService — за логику входа/регистрации; SessionManager — за создание/инвалидацию сессий; PasswordHasher — за хэширование. Интерфейсы/абстракции облегчают тестирование и замену реализаций.
- Пример/заметка: authService.login(username, password) вызывает userRepository.find(), user.verifyPassword(), sessionManager.create(). Подходит для больших систем, поддерживает инкапсуляцию и расширяемость.
3) Функциональное
- Структуры данных: неизменяемые структуры — ассоциативные массивы/деревья (Map username → UserRecord), идентификаторы сессий. Состояние передаётся явно как значение (или хранится в реф/атом/STM при необходимости).
- Контроль состояния: минимизация побочных эффектов — основные функции pure: register(state, userCreds) → newState, authenticate(state, creds) → (result, newState) либо use монады эффектов/IO/State-монаду для последовательности. Для внешних эффектов (БД, сеть) — явные эффекты/интерпретаторы.
- Распределение ответственности: маленькие чистые функции (validate, hashPassword, checkCredentials, createSession). Комбинирование через композицию и каррирование; слой эффектов (алгебра) отвечает за I/O. Тестируемость высокая, конкурентность проще благодаря неизменяемости.
- Пример/заметка: pipeline: credentials → validate → hash → addUser (возвращает новый user_map). Для реального приложения эффектную часть выносить в отдельные интерфейсы.
4) Логическое (прологоподобное)
- Структуры данных: факты и правила: user(username, password_hash, roles). session(session_id, username, expiry). Правила: can_access(User, Resource) :- user(User,_,Roles), role_allows(Roles, Resource).
- Контроль состояния: декларативная база фактов. Запросы/запрос-ответ — логическая верификация. Модификация состояния выполняется через операции assert/retract (императивные встраиваемые), либо через внешнюю БД; обычно базовая логика — декларативна, а обновления — отдельные команды.
- Распределение ответственности: ответственность выражена в наборах правил: правила аутентификации, правила авторизации, преобразования фактов. Клиент посылает запросы: authenticate? query user/verify. Управление сессиями — либо как динамические факты (assert(session(...))) либо через внешний сервис, а логика — в правилах.
- Пример/заметка: правило authenticate(U,P) :- user(U,PH,_), hash(P,H), PH = H. Для сложных транзакций потребуется гибридный подход (логика + внешние транзакции).
Ключевые отличия (кратко)
- Модель данных: процедурное — простые мутируемые контейнеры; ООП — объекты с инкапсулированным состоянием; функциональное — неизменяемые структуры; логическое — факты/правила.
- Состояние: процедурное/ООП — мутируется внутри; функциональное — возвращается новое состояние (или через моноды); логическое — факты в базе, изменение через assert/retract или внешние операции.
- Распределение ответственности: процедурное — функции/процедуры; ООП — объекты/сервисы; функциональное — набор чистых функций и слоев эффектов; логическое — декларация правил и отношений.
Рекомендации по безопасности и архитектуре общие для всех:
- Хранить только хэши паролей с солью (bcrypt/Argon2).
- Сессии с истечением и защитой от фиксации/угонов.
- Валидация входных данных и учёт атак (brute-force, timing attacks).
- Для продакшена комбинируйте: логика правил (авторизация) в декларативном виде, хранилище/сессии в ООП/процедурном слое, чистые функции для преобразований — функциональный стиль улучшает тестируемость.