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

Существуют ли задачи которые можно решить с помощью ООП, но недоступные для функционального программирования ?

Простой, казалось бы, вопрос.
Есть примеры таких задач ?

Первое что приходит спонтанно на ум, что вообще-то операционки пишутся на чистом С, а там таких задач...!!! Однако подумав начинает почему казаться, что нет таких задач. Хотя может я чего то не знаю и не понимаю...и канешн по ходу понятно, что с ООП удобнее, код более красивый, более гибкий... А если не секрет, к чему такой вопрос? ;) Потому как начинают приходить мысли о подвохе.

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

Операционки это конечно хороший пример, но для написания ядра не требуется ООП. А вот оболочку и всё остальное писать можно уже на чём угодно имея АПИ.

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

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

Наверное время пришло?! Пример в студию! А мы репки почешем. :) Полезнее будет, чем решать задачи с дурацкими шариками...

Я-то сам себе уже давно ответил =)) А хотел бы послушать мнение окружающих.
С самоконтролем я согласен полностью, а с "производственными расходами" - нет. Есть пример, когда "узким местом" в исполнении становится ООП? Мне кажется очень небольшой выигрыш в 99% задач.

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

Не трогайте шарики!!! В) Мне задачка очень понравилась. Особенно тем, что в ходе решения постоянно приходишь к неверному результату, пока наконец не вылезешь к верному.

Не сам ООП, а те действия (лишние), которые появляются при использовании ООП там, где этого делать не обязательно. Думаю, примеров можно найти в тырнете. Например, использование объектов вместо простых типов.

Вы. наверное, будете удивлены, но на Igf за 2007 год было несколько докладов об объектных моделях для 3д игр. Особливо там интеловцы распинались по поводу своей парадигмы (фабрики) для многопоточных игр, точнее для игр, которые должны использовать несколько ядер. Они предлагают разработчику игр использовать их модель в которой разработчик создает "действия" и инфраструктура сама эти действия синхронизирует, диспетчеризирует и т.д. Судя по графикам - выигрыш опупенный.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

bash (от англ. Bourne again shell) — усовершенствованная и модернизированная вариация командной оболочки Bourne shell. Одна из наиболее популярных современных разновидностей командной оболочки UNIX. Особенно популярна в среде GNU/Linux, где она часто используется в качестве командной оболочки по умолчанию.
ну а bin - это каталог, в котором запускной файл находится)

Я ему отменную книгу подогнал по башу, теперь она стала для него настольной и открыла широкие просторы для практической деятельности. ;)

ОО языки программирования, как и функциональные - Тьюринг-полные. Следовательно нет задач нерешаемых в рамках функциональной парадигмы и при этом решаемых в ООП.

Это ответ в широком смысле :)

О, формально полный ответ. В) А обратное?