Прошу прощения — отвечаю только на сам вопрос.
Процедурный стиль
- Структура данных: список/массив записей (словарей / struct):
- пример (псевдокод): task = {id, title, done, due}
- todo = [task, task, ...]
- (полей $3$–$4$ в простом случае)
- Операции (функции, мутирующие или возвращающие изменённый список):
- add_task(todo, task) — добавляет запись
- remove_task(todo, id)
- toggle_done(todo, id)
- list_tasks(todo, filter_fn)
- Тестирование: легко тестировать отдельные функции; проблемы, если функции мутируют глобальный список — нужно подготовить чистое состояние перед тестом.
- Расширяемость: добавление нового поля/функции требует правки множества функций — рост связности; простые изменения работают быстро, но масштабировать сложную логику неудобно.
- Подходит для: коротких скриптов, CLI-утилит, простых серверных эндпоинтов с небольшой логикой.
Объектно-ориентированный стиль
- Структура данных: классы с состоянием и поведением:
- class Task { id, title, done, due; methods: toggle(), update(...) }
- class TodoList { tasks: List; methods: add(task), remove(id), find(id), save(), load() }
- Операции: методы классов; можно внедрять интерфейсы/абстракции (например, репозиторий, уведомления).
- Тестирование: методы легко мокируются/изолируются; требуется мокать внешние зависимости (БД, сеть). Юнит-тесты на методы — естественны.
- Расширяемость: сильна — наследование, композиция, паттерны (наблюдатель, стратегия) упрощают рост функциональности. Риск: класс-«божья коровка» (god object) при плохом дизайне.
- Подходит для: GUI/клиентских приложений, сложных доменных моделей, когда объекты инкапсулируют состояние и поведение.
Функциональный стиль
- Структура данных: неизменяемые структуры (списки записей); задачи — простые иммутабельные объекты/рекорды.
- add_task(todo, task) -> new_todo
- toggle_done(todo, id) -> map/transform возвращает новую коллекцию
- reduce/filter/map для агрегаций и фильтрации
- Операции: чистые функции, высокоуровневые композиции, редьюсеры, ленивые трансформации.
- Тестирование: очень удобно — функции детерминированы, без побочных эффектов; легко писать property-тесты и композиционные тесты.
- Расширяемость: хорошо масштабируется через композицию и обобщённые функции; сложность — организация эффектов (I/O, состояние) — требует подходов (монад/эффектные системы).
- Подходит для: конкурентных/распределённых систем, undo/redo, сложных преобразований данных, потоковой обработки, реактивных фронтендов.
Логический (декларативный) стиль
- Структура данных: факты и правила (например, в Prolog):
- task(Id, Title, Done).
- due(Id, Date).
- overdue(Id) :- task(Id,_,false), due(Id,Date), today(T), Date < T.
- Операции: запросы/вычисления через унификацию и поиск с возвратом наборов решений; можно выражать ограничения и правила.
- Тестирование: тесты пишутся как запросы с ожидаемыми ответами; хорошо для верификации правил. Труднее тестировать побочные эффекты/императивный код.
- Расширяемость: добавление новых правил естественно; система правил может стать неочевидной при большой базе знаний. Хорошо выражает сложные логические/правилные зависимости.
- Подходит для: сложного поиска, планирования/расписаний с ограничениями, правил бизнес-логики, системы рекомендаций, задач типа "найти конфигурации, удовлетворяющие набору ограничений".
Короткое сравнение по критериям
- Тестирование: функциональный ≈ логический > объектный > процедурный (если процедурный мутирует общие состояния).
- Расширяемость: объектный (через композицию/паттерны) и функциональный (через композицию функций) сильнее; логический хорош для правил, процедурный — слабее для больших систем.
- Когда какой стиль явно лучше:
- процедурный: одноразовые скрипты, быстрые PoC;
- объектный: сложный UI, долгоживущие приложения с большим состоянием и событиями;
- функциональный: параллельная/реактивная логика, undo/redo, трансформации данных, тестируемость;
- логический: задачи с ограничениями/поиском/правилами (расписание, конфигурация, дедуктивная логика).
Практический совет
- Для реального todo-приложения часто смешивают подходы: ООП для GUI/моделей, функциональный для чистой бизнес-логики и трансформаций, логический для сложных правил/фильтрации, процедурный — как glue/скрипты. Выбор зависит от требований: конкуренция/предсказуемость → функциональный; богатая доменная модель и UI → ООП; сложные правила/поиск → логический.