[Slyer]

Задачи, которые решает программист:

1. Оценить реализацию(при необходимости написать ТЗ).
2. Спланировать сроки.
3. Спланировать архитектуру.
4. При необходимости - прототипировать.
5. Разработать. Самостоятельно, либо делегируя полномочия.
6. Отладить.
7. Разработать схему тестирования.
8. Разработать автоматические тесты(при необходимости).
9. Разработать документацию.
10. Сопровождать.
11. Поддерживать.
12. Расширять и вносить изменения.
13. Оптимизировать(по необходимости).

Процедурное программирование и ООП определяют подход к реализации всех этих пунктов. Но только ООП на уровне концепции поддерживает пункты 10, 11, 12.

Я думал, какой пример будет наиболее удачным, чтобы рассмотреть различия в реализации.
Решение маленьких задач. Требует прямого подхода к делу, в них нет смысла отвлекаться на сложную архитектуру программы. В таких случаях имеет смысл выбрать процедурный подход.
Для решения сложных задач. Таких как долгосрочные проекты, требующие поддержки, командной разработки и сопровождения - я бы выбрал только ООП.

Вот пример задачи. Дерево решений.
Необходимо спланировать и разработать систему принятия решений.
Условия:

1. Универсальность. Необходимо решать разного рода задачи.
2. Мобильность. Работа с деревом ведётся извне.
3. Решения должны поддерживать планирование.
4. Система работает в реальном времени. То есть во время выполнения задачи условия могут меняться.
5. Самое главное условие состоит в том, что одна система может наследовать функциональность другой, дополняя или урезая по необходимости.

Примеры использования.

1. Искусственный интеллект.
2. Система анализа данных.
3. Система производственного контроля.

Рассмотрим задачу на основе искусственного интеллекта.

Робот?

Проведём декомпозицию.
Сразу напрашивается разделение действий на две категории:

• простые
• сложные

Сложные действия могут состоять из простых. Например, перемещаться подразумевает преодолевать препятствия. Переносить предметы означает, что робот должен приблизиться к нему, поднять, переместиться в нужную позицию, положить предмет.

Это ещё не всё. Действия бывают моментальные и долгосрочные. Дать оценку данным - моментально. А движение - это долгосрочное действие, но оно не отменяет необходимость видеть, думать и т.д. Если во время движение появляется человек, то мы должны поздороваться и продолжить двигаться к цели.

Наша система должна поддерживать работу на всех уровнях. От точных команд "двинь пальцем", до "иди работай". В зависимости требований. При этом первый вариант состоит из набора действий, которые в свою очередь имеют свои составляющие.

Соответственно условия могут изменяться в любой момент. Если робот строит дом из кубиков и у него садится батарея, то он идёт подзарядить, затем возвращается к строительству.

И конечно "reuse". Все действия должны быть единообразно интегрированы друг в друга. Если необходимо сделать дополнительный вид движения, то оно должно учитывать условия и функциональность базовой реализации.

Сразу хочу предупредить. Решения в виде конечных автоматов общего вида или просто набора условных переходов, скорее всего приведёт к неработоспособности при постоянном усложнении.

Соответственно, из общего понятия "робот" можно перейти к понятию "боевой робот" или "домашний робот". При этом изменения в любом из базовых элементов системы должно поддерживаться в наследственных моделях.

Если есть отважные люди, которые осилили столь большой пост и заинтересовались, то было бы не плохо подумать и предложить модель решения.

Сейчас требуется ввести базовые понятия структур и общей организации.
Расписывать интерфейсы не стоит, это дело вторичное.

Я пока набросаю своё решение.