OOП, продолжение.

[Messiah]

По ходу порожняк гоняем. Чисто продекларирована идея, высказаны мнения (козе понятно, больше их не станет), однако чрезмерно затянувшаяся пауза с дальнейшим изложением, сильно смахивает на...лан, молчу, молчу. Интерес пропал.

[АлЁша]

Сообщение от Pitty

/... использовать их модель в которой разработчик создает "действия" и инфраструктура сама эти действия синхронизирует, диспетчеризирует и т.д. Судя по графикам - выигрыш опупенный.

Т.е. они получается фактически предлагают готовый движок в составе своей фабрики? Не думаю, что это идеальный универсальный вариант, особенно если учесть, что разработчик Майкрософт А как нужные графики выводить, это мы проходили :D Хотя честно говоря не слышал про эту фабрику, и объективно сказать не могу, так, общие рассуждения вслух :D

[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". Все действия должны быть единообразно интегрированы друг в друга. Если необходимо сделать дополнительный вид движения, то оно должно учитывать условия и функциональность базовой реализации.

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

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

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

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

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

[Slyer]

Сообщение от АлЁша

Думаю хороший движок современной 3d-игрушки невозможно сделать чисто в ООП.
ЗЫ я не спец по игрушкам, поэтому спорить не собираюсь, просто имхо

Движок современной игрушки - это практически всегда чистое ООП. =)

[Pitty]

Насчёт робота.
Мне кажется, оба метода: функциональный и объектный, имеют право на существование в этом случае. Удобство функционально - не надо создавать лишней инфраструктуры, удобство ООП - маштабируемость, но тогда приходится заранее продумывать все будущие ходы, чего сделать, в принципе, не возможно.
Например, движение. Базовая функция: AsyncResult BeginMoveTo(float X, Float Y, Float Z, Float Velocity)
Которая в свою очередь вызывает несколько функций: определение текущих координат, определение возможности проезда к нужным координатам/построение пути. Как только задан путь, вызывается функция AddMovingTask, которой передается путь, и она возвращает в свою очередь объект AsuncResult (ну еще колбэк нужен). В то же время существует бесконечный цикл, назовем его диспетчер задач, который, получив задание начинает его в цикле выбирать. При этом, вполне чётко можно проследить модульность: если изменится базовый алгоритм движения, необходимо будет изменить только тело функции DoStep, которая вызывается диспетчером. Если мы найдем более совершенный алгоритм нахождения пути - поменять только алгоритм метода поиска пути....
Мне кажется, как раз в этом случае создание объектной модели было бы излишним. Если вы строите робота-игрушку, у вас и аппаратные средства будут соответствующие, если вы строите боевого робота - там уже тем более будет не хватать аппаратных средств, т.к. скорость реакции и точность расчёта повышаются в несколько раз (да и количество задач тоже). По моим данным, в роботостроении мало применяется ООП. (Правда они немного устарели, года на 3-4).
Кстати, это пример чисто теоретический или Вы имеете практические намерения? В)
Не знаю, почему вы так обозлились на конечные автоматы: ведь практически реализуемый автомат всегда можно реализовать/оптимизировать, причём есть автоматические алгоритмы для таких вещей (универсальные).

[Messiah]

Сообщение от Pitty

...кусь...Не знаю, почему вы так обозлились на конечные автоматы: ведь практически реализуемый автомат всегда можно реализовать/оптимизировать, причём есть автоматические алгоритмы для таких вещей (универсальные).

Ой, ой...не к ночи ещё помянуть граф-схемы, автоматы Мили и Мура и теорему Баранова... и графы иже с ними.

[АлЁша]

Сообщение от Slyer

Движок современной игрушки - это практически всегда чистое ООП. =)

Именно поэтому я и писал: "хороший" движок. А то, что практически все нынешние движки сделаны в ООП и обуславливает то, что они все требуют топового "железа", да и на нем притормаживают, если по максимуму.

[Pitty]

Сообщение от АлЁша

Именно поэтому я и писал: "хороший" движок. А то, что практически все нынешние движки сделаны в ООП и обуславливает то, что они все требуют топового "железа", да и на нем притормаживают, если по максимуму.

Имхо в этом высказывании есть доля истины, но она небольшая. Тормозят они потому, что проектировались с расчётом на будущее. А загрузка железа выросла, потому что стали применяться новые, более совершенные, алгоритмы, более красивые и ёмкие текстуры да и количество полигонов выросло на несколько порядков. Если игра тормозит - надо купить новую видюху. Если вы купили новую видюху, вы будете гоняться за новыми играми, короые на вашей видюхе тоже будут тормозить. Замкнутый круг, который приносит прибыль как производителям видоускорителей (и другого железа), и фирмам, выпускающим играм. Вполне возможен даже некий сговор.

[Vulzscht]

Сообщение от Pitty

Имхо в этом высказывании есть доля истины, но она небольшая. Тормозят они потому, что проектировались с расчётом на будущее. А загрузка железа выросла, потому что стали применяться новые, более совершенные, алгоритмы, более красивые и ёмкие текстуры да и количество полигонов выросло на несколько порядков. Если игра тормозит - надо купить новую видюху. Если вы купили новую видюху, вы будете гоняться за новыми играми, короые на вашей видюхе тоже будут тормозить. Замкнутый круг, который приносит прибыль как производителям видоускорителей (и другого железа), и фирмам, выпускающим играм. Вполне возможен даже некий сговор.

влезу с небольшим оффтопом: самая лучшая игрушка - /bin/bash - требования минимальны, поле деятельности - необъемлемое, знаний требуется тоже немало, мозги поддерживает в актуальном состоянии для решения любых задач
кому непонятно - хоть консоль винды возьмите, правда графический режим убьется там только с консолью, а под юниксами - милое дело, иксы убил и вперед )))

[Pitty]

Сообщение от Vulzscht

влезу с небольшим оффтопом: самая лучшая игрушка - /bin/bash - требования минимальны, поле деятельности - необъемлемое, знаний требуется тоже немало, мозги поддерживает в актуальном состоянии для решения любых задач
кому непонятно - хоть консоль винды возьмите, правда графический режим убьется там только с консолью, а под юниксами - милое дело, иксы убил и вперед )))

простите за неграмотность и продолжение офтопа.. что есть /bin/bash ???