Вступление.
Совственно, к сабжу меня непосредственно привели 2 вещи
1) http://www.geocities.com/tablizer/oopbad.htm
пусть я не совсем согласен с автором касательно того, что ООП "в целом плохо", однако, как и у любой парадигмы (технологии, методологии, науки и вообще) у ООП, очевидно, есть границы применимости. Рекомендую сначала прочитать статью в приведенной ссылке.
2) Мой собственный печальный опыт. Недавно (2 мес назад) я закончил разработку собственной ООБД (на самом деле это очень простая штука, не пугайтесь), по прототипу www.prevayler.org Предполагалось применение этой ООБД в реальном проекте по учету кредитования.
Все хорошо, однако вот дальше разработки ООБД дело не пошло. Вся проблема заключалась в том, что я не смог получить удовлетворяющую меня модель предметной области с использованием ООБД. Сказались два фактора:
1) "Многоклассовость" реального мира, реальный мир неукладывается в рамки определенной строгой классификации (попытки обойти это подробно описаны здесь: http://www.rsdn.ru/Forum/Message.aspx?mid=833080&only=1

Автор: borisman2
Дата: 01.10.04

)
2) Навигационная сущность ООП. Для того, чтобы получить доступ к какому-то обхекту, необходимо сначала найти корневой объект и затем пройти по цепочке других объектов до нужного объекта. Вчера я с ужасом понял, что именно по такому пути шли навигационные базы данных, умершие с появлением РСУБД!!! Другие методы — например, назначение каждому обхетку OID или хуже того, применение экстентов — это ведь строго говоря, кусочки реляционного подхода, применненые к ООБД

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

Для моделирования действительности лучше применять реляционный подход. К сожалению, предметная область (читай, реальный мир) как правило настолько сложна, что описать ДАННЫЕ (читай, атрибуты сущностей и отношения между ними) — уже дело не из легких. Если же сюда подключить еще и поведение (читай ООП), все настолько усложнится, что впору бросать проект.

Для реализации ПРОЦЕССОВ происходящих в реальном мире лучше подходит процедурное программирование.

Для описания ТРАНСФОРМАЦИЙ ДАННЫХ (например, между разными БД) лучший кандидиат, несомненно, функциональное прораммирование.

Для описания УПРАВЛЕНИЯ и реализации РЕАКТИВНЫХ СИСТЕМ лучше всего подходит автоматное программирование (www.softcraft.ru)

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

Куда приткнуть логическое программирование, я, за недостатком образовния , просто ума не приложу.

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

Здравствуйте, Borisman2, Вы писали:

B>Для моделирования действительности лучше применять реляционный подход.
Как можно применить реляционный подход для моделирования? Для классификации — да, понятно. Особенно если сама задача формулируется в "табличных" категориях (например, тот же самый учет кредитования) — справочники, остатки на счетах, история выплат...
Но, во-первых, такие задачи тоже имеют к "действительности" не самое прямое отношение, все эти "проводки", "документы" и т.п. в живой природе не существуют, выдуманы людьми для облегчения финансового/управленческого учета ещё в докомпьютерную эру — не факт, что навсегда.
А, во-вторых, "классифокация" это не "моделирование", для моделирования нужны ещё и алгоритмы, которых реляционный подход нам не даст.
B> Если же сюда подключить еще и поведение (читай ООП), все настолько усложнится, что впору бросать проект.
Понятно ведь, что в большинстве случаев без "поведения" не обойтись, разве что потребуется написать что-нибудь уж совсем элементарное.

B>Для реализации ПРОЦЕССОВ происходящих в реальном мире лучше подходит процедурное программирование.
А каким образом можно реализовать эти процессы? Раз они происходят в реальном мире, значит он (мир) их и реализует. О чем речь, приведи примеры? О системах управления АЭС и т.п. бортовых компьютерах? И чем тут процедурный подход предочтительнее остальных?

Здравствуйте, eugals, Вы писали:

E>Здравствуйте, Borisman2, Вы писали:

E>Как можно применить реляционный подход для моделирования? Для классификации — да, понятно.
Ок, это вопрос терминологии. Назовите это классфикацией если угодно. Однако, мне больше нравится термин "модель данных".

E>Но, во-первых, такие задачи тоже имеют к "действительности" не самое прямое отношение, все эти "проводки", "документы" и т.п. в живой природе не существуют, выдуманы людьми для облегчения финансового/управленческого учета ещё в докомпьютерную эру — не факт, что навсегда.
Нет смысла работать с непосредственной действительностью, минуя проводки и документы. С философской точки зрения действительность вообще может не существовать, а существует лишь наше представление (читай, модель) действительности.

E>А, во-вторых, "классифокация" это не "моделирование", для моделирования нужны ещё и алгоритмы, которых реляционный подход нам не даст.
Реляционный подход "отхватывает" большой кусок действительности — данные. Процессы и данные моделируются прим помощи IDEF0 например. И затем автоматизируются при помощи программного кода (процедурного программирования, в частности)

E>А каким образом можно реализовать эти процессы? Раз они происходят в реальном мире, значит он (мир) их и реализует. О чем речь, приведи примеры? О системах управления АЭС и т.п. бортовых компьютерах? И чем тут процедурный подход предочтительнее остальных?
Скажем так, процессы необходимо не реализовать, а поддержать, автоматизировать. Реализовать — не правильное слово, прошу прощения. О чем конкретно речь... разрабатываю я систему учета заявок и кредитов в банке.

Здравствуйте, Borisman2, Вы писали:
B>2) Мой собственный печальный опыт. Недавно (2 мес назад) я закончил разработку собственной ООБД (на самом деле это очень простая штука, не пугайтесь), по прототипу www.prevayler.org Предполагалось применение этой ООБД в реальном проекте по учету кредитования.
B> Все хорошо, однако вот дальше разработки ООБД дело не пошло. Вся проблема заключалась в том, что я не смог получить удовлетворяющую меня модель предметной области с использованием ООБД. Сказались два фактора:
B> 1) "Многоклассовость" реального мира, реальный мир неукладывается в рамки определенной строгой классификации (попытки обойти это подробно описаны здесь: http://www.rsdn.ru/Forum/Message.aspx?mid=833080&only=1

Автор: borisman2
Дата: 01.10.04

)
B> 2) Навигационная сущность ООП. Для того, чтобы получить доступ к какому-то обхекту, необходимо сначала найти корневой объект и затем пройти по цепочке других объектов до нужного объекта. Вчера я с ужасом понял, что именно по такому пути шли навигационные базы данных, умершие с появлением РСУБД!!! Другие методы — например, назначение каждому обхетку OID или хуже того, применение экстентов — это ведь строго говоря, кусочки реляционного подхода, применненые к ООБД
Извини, что влезаю с некоторым оффтопом, но дело в том, что я как раз занят разработкой ODBMS. И мне принципиально интересен твой негативный опыт.
Вот ты критикуешь навигационную сущность ООП. А если бы ООП поддерживало столь же эффективный ассоциативный доступ, как и RDBMS? Это бы помогло?

S>Извини, что влезаю с некоторым оффтопом, но дело в том, что я как раз занят разработкой ODBMS. И мне принципиально интересен твой негативный опыт.
S>Вот ты критикуешь навигационную сущность ООП. А если бы ООП поддерживало столь же эффективный ассоциативный доступ, как и RDBMS? Это бы помогло?

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

Столь же эффективный ассоциативный доступ предполагает соотвтетствие "ключ"->"объект", что приводит нас ко всем известным РСУБД как это не печально. Т.е. в принципе, конечно, можно сделать такую фичу. И будет работать, и хорошо будет работать (может быть). И так и делают обычно, как я понял... Но зачем ??? Зачем вообще тогда объекты и сложная навигация между ними ?
Кто будет создавать ключи ? Если ООБД, то ключи будут иметь неудобоваримый вид (как, например, OID). Если пользователь, то какая же это ООБД ?
Или я чересчур драматизирую ?

Вообще, есть у меня такое нехорошее подозрение, что ООБД кроме дополнительной сложности ничего мне не дадут. А в общем говоря, проблема ведь не в ключах, а в том, что диаграммами классов по факту очень трудно описывать предметную область. Слишком уж строгие ограничения налагает иерархия классов на объекты. В реальном мире все может быть гораздо гибче.

Насчет навигационной сущности ООП, как правильно заметил этот (собака!) B. Jacobs здесь : http://www.geocities.com/tablizer/core1.htm

An OOP application will thus tend to look like a network of records (objects). Some of the links between records will be due to inheritance (our "parent" key as described in above footnote), and others will simply be references to other records, such as one might find in an OO "Strategy Pattern". This network of records is similar to the "network databases" (NDB's) of the 1960's, and object databases tend to share many characteristics with them, both the good and bad.

Блин, даже не знаю, что тут возразить...

На самом деле мне еще много хочется сказать, но сейчас я в печали и не могу адекватно воспринимать (моделировать) реальность

Поэтому отойду немножко, помомба напишу.

Здравствуйте, Borisman2, Вы писали:

B> 1) "Многоклассовость" реального мира, реальный мир неукладывается в рамки определенной строгой классификации (попытки обойти это подробно описаны здесь: http://www.rsdn.ru/Forum/Message.aspx?mid=833080&only=1

Автор: borisman2
Дата: 01.10.04

)
ОО подход как раз и исходит из предроложения многоклассовости мира. ИМХО, он наиболее явно отражает этот факт. Только надро изначально ориентироваться на возможность множественной классификации и все будет нормально.

B> 2) Навигационная сущность ООП. Для того, чтобы получить доступ к какому-то обхекту, необходимо сначала найти корневой объект и затем пройти по цепочке других объектов до нужного объекта. Вчера я с ужасом понял, что именно по такому пути шли навигационные базы данных, умершие с появлением РСУБД!!! Другие методы — например, назначение каждому обхетку OID или хуже того, применение экстентов — это ведь строго говоря, кусочки реляционного подхода, применненые к ООБД
ООБД, действительно, имеет свою область применения. А именно — случаи, когда есть большое количество классов и при этом количество экземпляров каждого класса невелико. В данном случае, РСУБД будет работать весьма неэффективно. Учитывая то, что сама сущность ООБД располагает к высокоуровневому интеллектуальному кешированию (на уровне объектов), навигационный доступ может быть весьма выгоден. Также, благодаря навигационному доступу, значительно упрощается разработка распределенных БД.

B>Для моделирования действительности лучше применять реляционный подход. К сожалению, предметная область (читай, реальный мир) как правило настолько сложна, что описать ДАННЫЕ (читай, атрибуты сущностей и отношения между ними) — уже дело не из легких.
Нет, я не согласен. Реляционный подход нельзя применять к описанию модели данных напрямую, необходимо сперва провести сложную процедуру нормализации, после которой от изначальной модели предметной области может не остаться и камня на камне. ОО подход применительно к БД предполагает прямой перевод ER модели предметной области к концептуальной модели БД, исходя их предположения, что если ER модель существует в реальной жизни, значит она оптимальна.

B>Если же сюда подключить еще и поведение (читай ООП), все настолько усложнится, что впору бросать проект.
это точно

Здравствуйте, Borisman2, Вы писали:

B>Столь же эффективный ассоциативный доступ предполагает соотвтетствие "ключ"->"объект", что приводит нас ко всем известным РСУБД как это не печально. Т.е. в принципе, конечно, можно сделать такую фичу. И будет работать, и хорошо будет работать (может быть). И так и делают обычно, как я понял... Но зачем ??? Зачем вообще тогда объекты и сложная навигация между ними ?
B>Кто будет создавать ключи ? Если ООБД, то ключи будут иметь неудобоваримый вид (как, например, OID). Если пользователь, то какая же это ООБД ?

А почему ты противопоставляешь реляционные запросы ОО-структуре? То что современные РСУЮД с ООП плохо совместимы еще не означает что несовместимы принципы. Например XPath, обладая вполне реляционной сущностью, как показывает практика, неплохо подходит в качестве языка запроса к объектным графам.

Здравствуйте, AndrewVK, Вы писали:

AVK>А почему ты противопоставляешь реляционные запросы ОО-структуре? То что современные РСУЮД с ООП плохо совместимы еще не означает что несовместимы принципы. Потому что:

1) Адекватно связать ОО структуру с реляционной базой — задача пока не решенная (да и вряд-ли будет когда-либо решена). Удобное отображение реляционных данных на ОО и наоборот вообще может оказаться задачей неразрешимой. Те, кто пользовался когда-либо слоями OR-маппинга знают, о чем идет речь. Все это происходит от того, что ОО модель и реляционная модель очень-очень разные вещи, построенные, между прочим, на разных принципах. Реляционная модель — данные, описываемые сущностями и отношениями, ОО медоль — данные и поведение, описываемые объектами. В частности, такая вот закавыка... В реляционной модели "все наружу", т.е. вся структура данных кишками смотрит на нас (ухмыляется ). В ОО модели отношения между объектами скрыты инкапсуляцией.
2) ИМХО ООБД и РСУБД никогда не будут совместимы, это миф. Все потуги добиться чего-то среднего (Обхектно-реляционные БД) привели лишь к большому кол-ву сложностей и, по сути, ни к чему хорошему. Я сторонник тов. Кодда и третьего манифеста.

AVK>Например XPath, обладая вполне реляционной сущностью, как показывает практика, неплохо подходит в качестве языка запроса к объектным графам.

Вы хотели сказать, объектной сущностью. Но это ничего не доказывает. Да, существуют языки запросов для ООБД. OQL например. И они совершенно нереляционные, а, скорее, обладают навигационными свойствами. Вспомните, в том же XPATH вы указываете путь до переменной (по сути навигация). Само название XPATH уже о многом говорит.

Здравствуйте, prVovik, Вы писали:

V>ОО подход как раз и исходит из предроложения многоклассовости мира. ИМХО, он наиболее явно отражает этот факт. Только надро изначально ориентироваться на возможность множественной классификации и все будет нормально.
Как Вы собираетесь это реализовать ??? единственный известный мне подход — множественная классификация в ML (по-моему, может быть я чего и путаю. Краем ужа слышал). Очень, очень интересно, как же это практически будет выглядеть???

B>> 2) Навигационная сущность ООП. Для того, чтобы получить доступ к какому-то обхекту, необходимо сначала найти корневой объект и затем пройти по цепочке других объектов до нужного объекта. Вчера я с ужасом понял, что именно по такому пути шли навигационные базы данных, умершие с появлением РСУБД!!! Другие методы — например, назначение каждому обхетку OID или хуже того, применение экстентов — это ведь строго говоря, кусочки реляционного подхода, применненые к ООБД
V>ООБД, действительно, имеет свою область применения. А именно — случаи, когда есть большое количество классов и при этом количество экземпляров каждого класса невелико. В данном случае, РСУБД будет работать весьма неэффективно. Учитывая то, что сама сущность ООБД располагает к высокоуровневому интеллектуальному кешированию (на уровне объектов), навигационный доступ может быть весьма выгоден. Также, благодаря навигационному доступу, значительно упрощается разработка распределенных БД.
Мне всегда было не ясно, что же такое это интеллектуальное кэширование и чем оно лучше, чем кэширование записей (читай, сущностей) в РСУДБ ?

V>Нет, я не согласен. Реляционный подход нельзя применять к описанию модели данных напрямую, необходимо сперва провести сложную процедуру нормализации, после которой от изначальной модели предметной области может не остаться и камня на камне. ОО подход применительно к БД предполагает прямой перевод ER модели предметной области к концептуальной модели БД, исходя их предположения, что если ER модель существует в реальной жизни, значит она оптимальна.
Нет такого перевода, миф это. Сначала придется иерархии классов строить. Причем завтра может выясниться, что иерархия уже не соответствует предметной области. Тут на форуме (по моему Vlad2) предлагал пример с зоопарком. Есть мол, в зоопарке животные и сторожа. Животных кормят и на них смотрят, сторожам платят. Все хорошо. Пишем приложение, которое разруливает все это. Послезавтра устанавливают в зоопарк сторожевых собак. Как с ними быть ???? Они — животные, но на них не смотрят, и они -сторожа, но им не платят Нужно будет СИЛЬНО переправить ОО модель. В случае реляционной модели все решается гораздо меньшей кровью, кстати.

Здравствуйте, Borisman2, Вы писали:

B>Вступление.
B>Совственно, к сабжу меня непосредственно привели 2 вещи
B> 1) "Многоклассовость" реального мира, реальный мир неукладывается в рамки определенной строгой классификации (попытки обойти это подробно описаны здесь: <b>http://www.rsdn.ru/Forum/Message.aspx?mid=833080&amp;only=1</b>

Автор: borisman2
Дата: 01.10.04

)
Прочитал этот пост с большим интересом. Но меня заинтересовал вопрос, почему ты сам решая правильно проблему не увидел её корень, а списал всё на недостатки ООП? В данном конретном случае поблема кроется не в ООП, а в том, что такие языки как C++, Java используют по сути статический подход в реализации парадигмы. В них во главе ставится принцип статической типизации и типовой безопасности. Есть и другие — динамические подходы в реализации ООП. Тот же Smalltalk, несмотря на то что ближе к классической реализации парадигмы (ближе к плюсам, чем к радикальным языкам — о них я расскажу ниже), подошёл бы в данной задаче намного лучше за счёт динамической типизации. А, например, в таком языке как Self, вообще отсутсвует понятие класс. Объекты не могут изменить свой тип, потому что у них его просто нет, но они могут на в процессе исполнения программы менять свой функционал и структуру (эволюционировать или деградировать), могут менять своих предков. И всё это находится в рамках объектно-ориентированой парадигмы, с одной стороны, и помогает реализовать "многоклассовость" мира с другой.

B> 2) Навигационная сущность ООП. Для того, чтобы получить доступ к какому-то обхекту, необходимо сначала найти корневой объект и затем пройти по цепочке других объектов до нужного объекта. Вчера я с ужасом понял, что именно по такому пути шли навигационные базы данных, умершие с появлением РСУБД!!! Другие методы — например, назначение каждому обхетку OID или хуже того, применение экстентов — это ведь строго говоря, кусочки реляционного подхода, применненые к ООБД

К сожалению это так. Просто потому, что программирование — это строгая дисциплина, не трепящая нечёткой логики (я не имею в виду алгоритмы нечёткого поиска, в данном случае я подразумеваю, что ни в одном языке программирования нет оператора типа "а почему бы и нет") и требующая однозначной идентификации взаимодействующих объектов. Это достигается либо через выделения корня, либо через присвоение идентификатора (что такое экстент к сожалению не знаю, поэтому сказать ничего не могу). Что хуже я не знаю... Корень требует, чтобы его все знали, или чтобы узлы иерархии постепенно передавались по цепочке вызовов (это кстати более правильный подход). Идентификаторы требуют централизованого хранилища от которого все зависят (по сути тот же корень), решения проблемы уникальности идентификатра и поиска объекта по его идентификатору.

B>Для моделирования действительности лучше применять реляционный подход. К сожалению, предметная область (читай, реальный мир) как правило настолько сложна, что описать ДАННЫЕ (читай, атрибуты сущностей и отношения между ними) — уже дело не из легких. Если же сюда подключить еще и поведение (читай ООП), все настолько усложнится, что впору бросать проект.

B>Для реализации ПРОЦЕССОВ происходящих в реальном мире лучше подходит процедурное программирование.

B>Для описания ТРАНСФОРМАЦИЙ ДАННЫХ (например, между разными БД) лучший кандидиат, несомненно, функциональное прораммирование.

B>Для описания УПРАВЛЕНИЯ и реализации РЕАКТИВНЫХ СИСТЕМ лучше всего подходит автоматное программирование (www.softcraft.ru)

Согласен с одним дополнением. Когда "действительность" смоделирована — взаимодействующие сущности выделены, их атрибуты, используемые в программе определены, отношения запротоколированы — никто не мешает построить по этой модели объектно-ориентированную, которая будет применяться непосредственно для разработки. При этом необходимо учесть ограничения и достоинства того или иного подхода в реализации парадигмы (см. выше замечание про динамические языки) и выбрать наиболее подходящий.

B>ООП хорошо для "внутреннего" использования, т.е. для работы с внутренними объектами, никак не связанными с объектами реального мира. Например, мой вебсервер является объектом, не имеющим аналогов в реальном мире. Например, подсистема управления транзакциями TransactionLog тоже к реальному миру имеет отдаленное весьма отношение. Т.е. ООП хорошо применять к таким объектам, над которыми мы имеем полную власть, т.е. над теми, которые мы сами придумали и сами изменяем при необходимости. Тогда не возникает такой ситуации, когда иерархия обектов перестает соответсвовать действительности.

А именно к такой модели от модели реального мира в идеале ты и должен придти... Ещё раз подчеркну — в идеале.

B>Куда приткнуть логическое программирование, я, за недостатком образовния , просто ума не приложу.

Для реализации искусственного интеллекта .

B>Заключение
B>В общем, это довольно сумбурная попытка определить границы применимости каждой парадигмы. Если кто-нибудь знает о подобных попытках, проводимых в прошлом, просьба сообщить. Если у кого есть собственные соображения о границах применимости той или иной парадигмы — просьба высказываться.

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

Здравствуйте, Borisman2, Вы писали:

B>Здравствуйте, prVovik, Вы писали:

V>>ОО подход как раз и исходит из предроложения многоклассовости мира. ИМХО, он наиболее явно отражает этот факт. Только надро изначально ориентироваться на возможность множественной классификации и все будет нормально.
B>Как Вы собираетесь это реализовать ??? единственный известный мне подход — множественная классификация в ML (по-моему, может быть я чего и путаю. Краем ужа слышал). Очень, очень интересно, как же это практически будет выглядеть???

вот варианты ручной реализации на плюсах, идея должна быть понятна, некоторые языки поддерживают это явно (даже не через библиотеки, а на уровне своих спецификаций):

// Объект с изменяемым типом
class MultiTypeObject
{
public:
    void CallMethod(const std::string &methodName, void *args, void **results)
    {
        Method *method = obj_->FindMethod(methodName);
        method->Call(args, results);
    }

    void ChangeObjectType(Object *newObj)
    {
        obj_ = newObj;
    }
private:
    Object *obj_;
};

// Объект с изменяемым предком
class MyObject
{
public:
    void CallMethod(const std::string &methodName, void *args, void **results)
    {
        if(methods_.find(methodName) != methods_.end())
        {
            methods_[methodName]->Call(args, results);
        }
        else
        {
            parent_->Call(methodName, args, results);
        }
    }

private:
    std::map<std::string, Method> methods_;
    Object *parent_;
};

// Объект с изменяемым списком методов
class MyObject
{
public:
    void AddMethod(const std::string &methodName, Method *method)
    {
        methods_[methodName] = method;
    }

    void RemoveMethod(const std::string &methodName)
    {
        methods_.remove(methodName);
    }

    void CallMethod(const std::string &methodName, void *args, void **results)
    {
        if(methods_.find(methodName) != methods_.end())
        {
            methods_[methodName]->Call(args, results);
        }
    }

    void ChangeParent(Object *newParent)
    {
        parent_ = newParent;
    }

private:
    std::map<std::string, Method> methods_;
};

Всё это можно объединить в одном.

Здравствуйте, Mr. None, Вы писали:

MN>вот варианты ручной реализации на плюсах, идея должна быть понятна, некоторые языки поддерживают это явно (даже не через библиотеки, а на уровне своих спецификаций):

Случайно ткнул на кнопку отправить, второй вариант должен быть так:
MN>

MN>// Объект с изменяемым предком
MN>class MyObject
MN>{
MN>public:
MN>    void CallMethod(const std::string &methodName, void *args, void **results)
MN>    {
MN>        if(methods_.find(methodName) != methods_.end())
MN>        {
MN>            methods_[methodName]->Call(args, results);
MN>        }
MN>        else
MN>        {
MN>            parent_->Call(methodName, args, results);
MN>        }
MN>    }

MN>    void ChangeParent(Object *newParent)
MN>    {
MN>        parent_ = newParent;
MN>    }

MN>private:
MN>    std::map<std::string, Method> methods_;
MN>    Object *parent_;
MN>};

Здравствуйте, Mr. None, Вы писали:

MN>Здравствуйте, Borisman2, Вы писали:
MN>вот варианты ручной реализации на плюсах, идея должна быть понятна...

Да, идея ясна. Остался за кадром вопрос — как быть с добавлением/удалением переменных и в особенности с ПЕРЕНОСОМ переменных из одних классов в другие. Но это не принципиально.

У меня есть более простое решение ))

typedef std::map<const char*, int, ltstr> OBJECT;

void getName(OBJECT &obj)
{
  return obj["name"];
}
void setName(OBJECT &obj, std::string name)
{
  obj["name"] = name;
}
void addA(OBJECT &obj, int a)
{
  obj["a"]+=a;
}

void addB(OBJECT &obj, int b)
{
  obj["b"]+=b;
}
// И вот теперь что хотим, то и делаем
myObj  = OBJECT();
myObj["a"]=0;
addA(myObj, 2);
setName(a, std::string("hi there"))

Короче идея в том, чтобы объекты представлять в виде маппингов имя атрибута->атрибут
А методы к ним можно применять какие хошь...

Это малость странный подход, который рот не поворачивается назвать ООП.

Ну а кроме шуток.... Вопрос более серьезный: Зачем нам ООП с "плавающими" иерархиями ? Есть ли в нем вообще смысл? Не легче ли вернуться вообще к процедурному подходу и забыть об объектах как таковых ?

Здравствуйте, Borisman2, Вы писали:

B>Ну а кроме шуток.... Вопрос более серьезный: Зачем нам ООП с "плавающими" иерархиями ? Есть ли в нем вообще смысл? Не легче ли вернуться вообще к процедурному подходу и забыть об объектах как таковых ?

А если кроме шуток, то упомянутый мной язык Self предоставляет как раз такие возможности:
— динамическая смена предков объекта в процессе исполнения;
— динамическое формирование списка методов и атрибутов объекта (там это называется одним словом "слот").

Зачем это надо?
Вспомним шаблон проектирования STATE. Разве это не есть реализация в плюсах именно этой возможности Self`а: наследлвание не через статическое копирование кода предка в код потомка, а через агрегирование объектом потомка объекта предка, с возможностью динамической замены последнего.
В случае процедурного подхода это реализуется только громадным switch`ем, или сохранением указателя на процедуру, что суть есть то же ООП, но для не ООП языка...
Я надеюсь ответил на вопрос?

Здравствуйте, Borisman2, Вы писали:

B>Короче идея в том, чтобы объекты представлять в виде маппингов имя атрибута->атрибут
B>А методы к ним можно применять какие хошь...

B>Это малость странный подход, который рот не поворачивается назвать ООП.

Именно этот подход применятеся в любом языке с динамической типизацией. К объекту языка Smalltalk вы можете применить абсолютно любой вызов (вызвать любой метод), если этот вызов объектом обрабатывается, он его обработает, если нет, то скинет исключение (точнее сначала вызовется некая функция по умолчанию, которая по дефолту выкидывает исключение).

Здравствуйте, Mr. None, Вы писали:

MN>Прочитал этот пост с большим интересом. Но меня заинтересовал вопрос, почему ты сам решая правильно проблему не увидел её корень, а списал всё на недостатки ООП? В данном конретном случае поблема кроется не в ООП, а в том, что такие языки как C++, Java используют по сути статический подход в реализации парадигмы. В них во главе ставится принцип статической типизации и типовой безопасности. Есть и другие — динамические подходы в реализации ООП. Тот же Smalltalk, несмотря на то что ближе к классической реализации парадигмы (ближе к плюсам, чем к радикальным языкам — о них я расскажу ниже), подошёл бы в данной задаче намного лучше за счёт динамической типизации. А, например, в таком языке как Self, вообще отсутсвует понятие класс.
Где бы найти self для Windows ????

MN>Объекты не могут изменить свой тип, потому что у них его просто нет, но они могут на в процессе исполнения программы менять свой функционал и структуру (эволюционировать или деградировать), могут менять своих предков. И всё это находится в рамках объектно-ориентированой парадигмы, с одной стороны, и помогает реализовать "многоклассовость" мира с другой.
Интересная концепция. Однако, в такой постановке понятие класса и объекта настолько размывается, что лично мне вообще становится трудн оего увидеть.

MN>К сожалению это так. Просто потому, что программирование — это строгая дисциплина, не трепящая нечёткой логики (я не имею в виду алгоритмы нечёткого поиска, в данном случае я подразумеваю, что ни в одном языке программирования нет оператора типа "а почему бы и нет") и требующая однозначной идентификации взаимодействующих объектов. Это достигается либо через выделения корня, либо через присвоение идентификатора (что такое экстент к сожалению не знаю, поэтому сказать ничего не могу).
Экстент — это, грубо говоря, список всех объектов заданного типа(класса).

MN>Что хуже я не знаю... Корень требует, чтобы его все знали, или чтобы узлы иерархии постепенно передавались по цепочке вызовов (это кстати более правильный подход).
Иногда нас вовсе не интересует корень, а интересуют объекты, лежащие далеко в глубине. Требование навигации от корня значительно усложняет как работу с СУБД так и снижает адаптивность СУБД. Вспомнить MUMPS и иерархические БД. Там именно так все и было, все данные были завязаны в строгую иерархическую структуру. Именно требование ПРИНАДЛЕЖНОСТИ одних данных другим (насколько я понимаю) и явилось причиной крушения иерархических БД. По факту, одни объекты редко принадлежат другим. Работник только с одной точки зрения принадлежит к отделению компании. А с другой точки зрения его и уволить могут и может он владеть компанией и еще черти что может случиться.

MN>Идентификаторы требуют централизованого хранилища от которого все зависят (по сути тот же корень), решения проблемы уникальности идентификатра и поиска объекта по его идентификатору.
Если есть центральный корень — ключи не нужны. Если мы собираемся идентифицировать отдельные объекты независимо, тогда нужны ключи (и, в принципе, не нужен центральный корень)

MN>Согласен с одним дополнением. Когда "действительность" смоделирована — взаимодействующие сущности выделены, их атрибуты, используемые в программе определены, отношения запротоколированы — никто не мешает построить по этой модели объектно-ориентированную, которая будет применяться непосредственно для разработки.
Никогда действительность до конца не будет смоделирована. Завтра придет босс и скажет — а ну-ка Семен Семеныч, сделай-ка нам вот так и вот эдак...
Вопрос о том, что модель когда-то будет соответствовать действительности вообще не стоит. Не будет. Вопрос стоит так: какой подход гибче, какой подход легче модифицировать? Мне кажется, реляционную модель легче изменить, потому что она проще.

B>>ООП хорошо для "внутреннего" использования, т.е. для работы с внутренними объектами, никак не связанными с объектами реального мира. Например, мой вебсервер является объектом, не имеющим аналогов в реальном мире. Например, подсистема управления транзакциями TransactionLog тоже к реальному миру имеет отдаленное весьма отношение. Т.е. ООП хорошо применять к таким объектам, над которыми мы имеем полную власть, т.е. над теми, которые мы сами придумали и сами изменяем при необходимости. Тогда не возникает такой ситуации, когда иерархия обектов перестает соответсвовать действительности.

MN>А именно к такой модели от модели реального мира в идеале ты и должен придти... Ещё раз подчеркну — в идеале.
Ок, в идеале, в случае если мы делаем ООП модель, у нас есть четкая иерархическая структура классов, описывающих предметную область с четко определенными интерфейсам и т.д. и т.п. Идеал недостижим. Причем в одних областях он более недостижим чем в других. Если Вы пишете ООП библиотеку для разбора XML — это одно. Если Вы рисуете ОО модель товарно-денежных отношений между завскладом, товароведом, менеджером, бужгалтером, посавщиами и т.д. — это уже совсем-совсем другой коленкор.

B>>Куда приткнуть логическое программирование, я, за недостатком образовния , просто ума не приложу.
MN>Для реализации искусственного интеллекта .
Куда там! Мне бы со своим естественным разобраться.

B>>Заключение
B>>В общем, это довольно сумбурная попытка определить границы применимости каждой парадигмы. Если кто-нибудь знает о подобных попытках, проводимых в прошлом, просьба сообщить. Если у кого есть собственные соображения о границах применимости той или иной парадигмы — просьба высказываться.

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

Здравствуйте, Mr. None, Вы писали:

MN>В случае процедурного подхода это реализуется только громадным switch`ем, или сохранением указателя на процедуру, что суть есть то же ООП, но для не ООП языка...
Во-первых, насчет свича — вопрос спорный. Не факт.
http://www.geocities.com/tablizer/myths.htm

Myth: OOP eliminates the "complexity" of "case" or "switch" statements
This claim results in some of the most lengthy and heated debates I have ever been in. Some issues relate to certain syntax of certain languages, such as C's silly, archaic "break" statement. Outside of language-specific syntax, it appears to mostly be an issue of "aspect grouping". There are (at least) two dimensions involved in examples compared, and one must pick which dimension to favor at the expense of the others. In other words, there is no free lunch. Program code is pretty much a one-dimensional medium and we are trying to project two dimensions onto it. Something is going to have to be sacrificed.

MN>Я надеюсь ответил на вопрос?
В общем, да. Только я пока не понял. Нужно думать.

Здравствуйте, Mr. None, Вы писали:

MN>Именно этот подход применятеся в любом языке с динамической типизацией. К объекту языка Smalltalk вы можете применить абсолютно любой вызов (вызвать любой метод), если этот вызов объектом обрабатывается, он его обработает, если нет, то скинет исключение (точнее сначала вызовется некая функция по умолчанию, которая по дефолту выкидывает исключение).

Верно. Я сам на Питоне пишу. Однако идея динамического добавления методов пока в голову мою плохо укладывается.