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

[Slyer]

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

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

[Messiah]

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

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

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

[Slyer]

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

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

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

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

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

[Pitty]

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

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

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

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

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

[Slyer]

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

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

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

[АлЁша]

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

Есть пример, когда "узким местом" в исполнении становится ООП? Мне кажется очень небольшой выигрыш в 99% задач.

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

[Pitty]

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

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

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

[Messiah]

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

Нет подвоха.
На вскидку я знаю пару пунктов, которые нельзя реализовать без ООП...кусь...

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

[Pitty]

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

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

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

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

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

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

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

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

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