Re[5]: Границы применимости парадигм программирования - Философия программирования

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

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

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

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

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

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

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

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

, просто ума не приложу.

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

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

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

B>Вступление.
B>Совственно, к сабжу меня непосредственно привели 2 вещи
B>1) http://www.geocities.com/tablizer/oopbad.htm
B> пусть я не совсем согласен с автором касательно того, что ООП "в целом плохо", однако, как и у любой парадигмы (технологии, методологии, науки и вообще) у ООП, очевидно, есть границы применимости. Рекомендую сначала прочитать статью в приведенной ссылке.
Аналогично, не совсем согласен с автором, особенно с Table-Oriented Programming. Еще одна грыжа, не более того.

B>2) Мой собственный печальный опыт. Недавно (2 мес назад) я закончил разработку собственной ООБД (на самом деле это очень простая штука, не пугайтесь), по прототипу www.prevayler.org Предполагалось применение этой ООБД в реальном проекте по учету кредитования.
Посмотрел www.prevayler.org, сильно не дотягивает до нормальной OOCУБД.
B> Все хорошо, однако вот дальше разработки ООБД дело не пошло. Вся проблема заключалась в том, что я не смог получить удовлетворяющую меня модель предметной области с использованием ООБД. Сказались два фактора:
B> 1) "Многоклассовость" реального мира, реальный мир неукладывается в рамки определенной строгой классификации (попытки обойти это подробно описаны здесь: http://www.rsdn.ru/Forum/Message.aspx?mid=833080&only=1)
Тяжело описать просто то, что в реальном мире сложно устроено. Не надо, это перекладывать на недостатки метода. В реальном мире, пока человек не поймет как вещь устроена, он считает ее простой, и относится к ней как к некоторой абстракции. Хотя в некоторых случаях, недостатков у методики вагон, но и всегда есть нормальный выход из проблемы.
B> 2) Навигационная сущность ООП. Для того, чтобы получить доступ к какому-то обхекту, необходимо сначала найти корневой объект и затем пройти по цепочке других объектов до нужного объекта. Вчера я с ужасом понял, что именно по такому пути шли навигационные базы данных, умершие с появлением РСУБД!!! Другие методы — например, назначение каждому обхетку OID или хуже того, применение экстентов — это ведь строго говоря, кусочки реляционного подхода, применненые к ООБД
Наличие у обхетка OID, самое ценное что есть в ООСУБД. Это и есть нормальная идентификация объекта в отличие от реляционного подхода. Вообще, насколько я понял, ваше пессимистическое отношение в основном базируется на prevayler. Повторю, сильно недотягивает до нормального ООСУБД. Для того чтобы построить ООБД, нужно в него вложится не меньше чем в Oracle. И даже больше, поскольку внутренняя структура значительно сложнее. В основном ООСУБД, к сожалению, развиваются только на бумаге. Нормальных реализаций, даже в стандарте ODMG я не видел до сих пор. А стандарт вышел и умер до фигищи времени назад. Я не очень верю, что полноценная база данных может быть написана небольшой группой энтузиастов за короткое время.

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

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

1. Для моделирования действительности, лучше применять методы и инструменты, которые имеешь, знаешь и умеешь пользоваться. Для всего этого, и существует методы проектирования, начиная от Use-case'ов до дизайна программы. Что касается проблемы персистентности объектов, то это всего лишь небольшая часть всего этого процесса.
2. Сравнение РСУБД и ООСУБД, во многих сообщениях данного топика некорректно. ООСУБД содержит не только состояние объектов, но и его поведение. Соответсвенно, когда мы изменяем некоторое поведение, почему то обсуждается, насколько это легко сделать в реляционной структуре, но никак не затрагивается вопрос, что выше находится бизнес-логика объекта, которая тоже будет изменена. Соответсвенно, внесение изменений в реляционную+бизнес-объекты и ООСУБД, в принципе равнозначны.

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

PS: Существует достаточно много очень интересных парадигм, о которых все говорят и дивятся. Действительно, очень правильные вещи. Так сказать, двигают науку. Но в коммерции не проходят обычно по двум причинам. 1. Быстрота разработки. 2. Скорость выполнения. И маркетинг здесь не причем.

С уважением, Gleb.

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

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

По поводу классов

ООП заставляет программиста думать о предметной области в терминах объектов, но не классов объектов! Зачем Вам классы? Зачем Вам наследование классов? Если классификация оказывается полезной — хорошо, если классы бесполезны — тоже ничего страшного! ООП и Классы вовсе не близнецы-братья. Первичными являются именно объекты. Классы — лишь один из способов создавать объекты ни чуть не лучший других. Вот, например, другой способ: Программист садится за компьютер чтобы спроектировать новый объект. Он запускает специальный мастер и создает пустой объект. Этот объект персистентный. Программист может выключить компьютер, а объект сохраниться на диске. Придя на работу на следующий день, программист продолжит выращивание объекта дальше. На протяжении всего этапа проектирования/разработки объект будет живой. Объект живет в специальной среде. Когда компьютер выключается, объект сохраняется. После включения компьютера, объект продолжает жить дальше. Когда программист вырастит объект (добавляя к нему свойсва, методы и т.д.) до нужных ему "размеров", тогда программист сможет этот объект, например, продавать другим программистам. Но никакого исходного кода этого объекта не существует! Есть просто сам живой объект. Размножается он с помощью клонирования. Свой бинарный код он помнит сам. Если он попал (через сеть) на другой компьютер с другой архитектурой, то свой бинарный код он автоматически адаптирует в подходящий (например в 64 разрядный). Нету никаких классов, так как просто нету исходников, вообще нету!

По поводу ООБД

ОО программа в действии — это конгломерат объектов.Вот у нас есть конгломерат объектов взаимно ссылающихся друг на друга. Они находятся в оперативной памяти. Если компьютер выключить, то вся информация пропадет. Таким образом надо чтобы все объекты были персистентными и нужен механизм восстанавливающий все взаимные ссылки между объектами после загрузки этого конгломерата объектов обратно в оперативную память машины. Все это реализовывается элементарно. Например, у меня на Delphi это заняло всего около 2 тысяч строчек кода (в принципе, можно и меньше). То есть никакая ООБД вовсе не нужна до тех пор пока все объекты убираются в оперативной памяти. Проблема приходит когда количество объектов таково, что оперативной памяти компьютера не достаточно для их содержания. Объекты вместе с их взаимными ссылками надо хранить на диске/в сети на сервере/в интернете и ли еще где... В оперативной памяти все они уже не уберуться. Вот тут нужен механизм называемый ООБД. Но что конкретно нужно? Корень проблемы кроется в конечности размеров оперативной памяти, а нам хочется иметь, потенциально, бесконечную память. Так ведь? У нас есть модель бесконечной памяти. Мы создаем гигантские конгломераты (персистентных) объектов произвольным образом ссылающихся друг на друга. И хотим работать с этими титанами так как будто они все расположены в оперативной памяти нашего компьютера. Механизм, который создаст для нас работающую абстракцию модели бесконечной памяти — вот единственная цель ООБД. Что нам еще от нее требовать? Все остальное у нас и так есть! В идеале ООБД должна быть интегрирована с языком программирования и с операционной системой. Так что бы программист просто самым обычным способом писал самую обычную программу, вот только работающую с неограниченно большими количествами взаимосвязанных объектов, и при этом совершенно не задумывался бы о том что реально количество оперативной памяти очень ограничено. Там где-то стоят стойки из жестких дисков на которых реально записаны (персистентные) объекты, а может они доставляются через сеть, но программисту предоставлена абстракция бесконечной памяти, вот он с ней и работает точно также как в настоящее время работает с небольшими количествами персистентных объектов целиком убирающихся в оперативной памяти.

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

GZ>1. Если обращение происходит только к внутренним данным объекта, то все нормально, и все как в РСУБД c их кортежами и экстентами.
Верно
GZ>2. Для сторед процедур можно построить и сохранить планы выполнения.
Верно, с оговорками. А как же if? а циклы?
GZ>Если запрошена проперть у ООСУБД, нельзя точно спрогнозировать что она для себя потребует в процессе выполнения.
Почему это невозможно?
GZ>Внутренняя логика метода, со всеми if'ами и switch'ами, наследованием, перекрестными вызовами, может быть достаточно сложна для этого.
Хм. На первый взгляд, ничего сверхъестественного.
GZ> Для этого отслеживают статистику, что было запрошено при выполнении этой проперти в прошлые разы.
А это кто например? Можно ссылку на ООСУБД, которая это умеет?
GZ>Но вполне понятно, что при редком попадании в какой-то if, вся эта стстистика летит насмарку.
GZ>Потому и называется интелектуальной, потому что реализовать простыми способами невозможно. Одна из фич, за которую критикуют ООСУБД.
Ну, зато у нас есть сложные способы. Я вот сейчас упражняюсь в построении одного из них. Возможно, я и упрусь в какой-то непреодолимый предел.
Уже сейчас очевидно, что далеко не во всех случаях можно будет получить 100% оптимальный план запроса. Основные заметные препятствия — рекурсия/циклы и исключения.
То есть вряд ли удастся привести предикат вида

Factorial(self.Salary)<120

к предикату вида

self._salary < 5

А это, в свою очередь, не даст использовать индекс. Но лично мне греет душу смутное ощущение, что факториалы применяются в реальном софте, ворочающем гигабайтами, очень редко. И что в практических случаях из запроса удастся выделить предикат, достаточно селективный для того, чтобы снизить стоимость выполнения запроса до приемлемой.

Ну вот С++ тоже далеко не всегда может вполнить инлайнинг; тем не менее, его включение во многих случаях приводит к заметному росту производительности. Например, насколько мне известно, STL весьма чувствителен к поддержке инлайнинга, т.к. его применение очень много где из кучи взаимных вызовов и проверок сворачивается, грубо говоря, в rep stosd.

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

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

P>Я считаю, что ООП и конкретно С++ очень неплохой способ грамотно выражать свои мысли.
Ух. Я Вам искренне завидую. С++ не люблю давно и прочно, наверное от того, что это был мой второй язык программирования после Basic много-много лет назад.

P>Но вот только этой грамотности нелегко научиться.
Все, чему сложно научиться, скорее всего содержит элемент ненужной сложности. Считаю, что самым верным является как раз самый простой подход к задаче.

P>Научить всех членов команды использовать STL — и то неплохо будет.
Кстати, у STL и ООП ничего общего. Помнится, автор STL сильно не любил ООП. Можно даже ссылочку найти...

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

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

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

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

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

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

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

B>Вступление.
B>Совственно, к сабжу меня непосредственно привели 2 вещи
B> 1) "Многоклассовость" реального мира, реальный мир неукладывается в рамки определенной строгой классификации (попытки обойти это подробно описаны здесь: <b>http://www.rsdn.ru/Forum/Message.aspx?mid=833080&only=1</b>)
Прочитал этот пост с большим интересом. Но меня заинтересовал вопрос, почему ты сам решая правильно проблему не увидел её корень, а списал всё на недостатки ООП? В данном конретном случае поблема кроется не в ООП, а в том, что такие языки как C++, Java используют по сути статический подход в реализации парадигмы. В них во главе ставится принцип статической типизации и типовой безопасности. Есть и другие — динамические подходы в реализации ООП. Тот же Smalltalk, несмотря на то что ближе к классической реализации парадигмы (ближе к плюсам, чем к радикальным языкам — о них я расскажу ниже), подошёл бы в данной задаче намного лучше за счёт динамической типизации. А, например, в таком языке как Self, вообще отсутсвует понятие класс. Объекты не могут изменить свой тип, потому что у них его просто нет, но они могут на в процессе исполнения программы менять свой функционал и структуру (эволюционировать или деградировать), могут менять своих предков. И всё это находится в рамках объектно-ориентированой парадигмы, с одной стороны, и помогает реализовать "многоклассовость" мира с другой.

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

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

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

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

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

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

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

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

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

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

, просто ума не приложу.

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

.

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

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

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Реляционная алгебра мне известна.
В таком случае тебе, пожалуй, должна быть понятна мотивация изобретателей ODMG OQL. Почему-то их совершенно не удовлетворила сама по себе поддержка бесконечной памяти.

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

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

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

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

... << RSDN@Home 1.1.4 beta 3 rev. 244>>

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

B>1) Адекватно связать ОО структуру с реляционной базой — задача пока не решенная (да и вряд-ли будет когда-либо решена). Удобное отображение реляционных данных на ОО и наоборот вообще может оказаться задачей неразрешимой. Те, кто пользовался когда-либо слоями OR-маппинга знают, о чем идет речь. Все это происходит от того, что ОО модель и реляционная модель очень-очень разные вещи, построенные, между прочим, на разных принципах. Реляционная модель — данные, описываемые сущностями и отношениями, ОО медоль — данные и поведение, описываемые объектами. В частности, такая вот закавыка... В реляционной модели "все наружу", т.е. вся структура данных кишками смотрит на нас (ухмыляется

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

Еще раз — ты путаешь реляционные СУБД в их современном виде и реляционную структуру как принцип. Современные РСУБД в качестве аргумента реляции используют наиболее примитивную структуру из возможных — плоский список. Отсюда и проблемы с хранением объектов. Уже в XML с этим проблем на порядок меньше.

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

B>Вы хотели сказать, объектной сущностью.

Отнюдь. Если выкинуть иерархические фишки, то отличие между XPath и SQL минимально.

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

Нет. Навигация предполагает наличие курсора, а его в XPath нет. Путь в нем по сути аналогичен имени таблицы в SQL.

B> Само название XPATH уже о многом говорит.

О чем?

... << RSDN@Home 1.1.4 beta 3 rev. 248>>

Здравствуйте, Borisman2, большое спасибо за поднятую тему и ссылки.
Но вот читал эту дискуссию и подумал: границы применимости в наших мозгах.
Типа, если у тебя есть молоток, то все в мире превращается в гвозди.
Я считаю, что ООП и конкретно С++ очень неплохой способ грамотно выражать свои мысли.
Но вот только этой грамотности нелегко научиться.
И цена использования какой-нибудь теоретически не новой двойной диспетчеризации
в конкретном проекте может быть весьма велика — я говорю о затратах на изучение
Loki или Boost, или повторное изобретение и отладку отечественных самокатов.
Научить всех членов команды использовать STL — и то неплохо будет.

У, стали проги мои стожуковыми...Устал жутко...

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

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

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

... << RSDN@Home 1.1.4 beta 3 rev. 215>>

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

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

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

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

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

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

... << RSDN@Home 1.1.4 @@subversion >>

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

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

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

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

Нужно будет СИЛЬНО переправить ОО модель. В случае реляционной модели все решается гораздо меньшей кровью, кстати.

Здравствуйте, 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 вы можете применить абсолютно любой вызов (вызвать любой метод), если этот вызов объектом обрабатывается, он его обработает, если нет, то скинет исключение (точнее сначала вызовется некая функция по умолчанию, которая по дефолту выкидывает исключение).

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

B>Это малость странный подход, который рот не поворачивается назвать ООП.
И совершенно напрасно не поворачивается. JavaScript устроен именно так, только немношко побогаче. Не факт, что он есмь спасение для бизнес-задач, но это не отменяет его объектности.

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

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

B>Где бы найти self для Windows ????

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

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

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

B>Экстент — это, грубо говоря, список всех объектов заданного типа(класса).
Спасибо, буду знать

.

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

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

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

Выше я уже высказался на эту тему, для моделирования финансовых отношений даже реляционная модель не всегда подходит и виноваты в этом не мы, а наш мин. фин

.

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

, просто ума не приложу.
MN>>Для реализации искусственного интеллекта

.
B>Куда там! Мне бы со своим естественным разобраться.

без

разобраться сложно и с искусственным и тем более со своим

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

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

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

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

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

Пример.
Миксин-классы в C++-подобных языках удобнее всего реализовывать с помощью шаблонов. В C#-пе шаблоны отсутсвуют, но .NET предоставляет функционал по генеарции классов и добавлению к ним методов прямо во время исполнения программы (Reflection) иногда эти возможности задействуют в шарпе для автоматической генерации миксин-классов в процессе исполнения.

Насчёт эволюционирования объектов задвигать не буду, потому что пока сам реально не столкнёшься это похоже на теорию существования сферических коней в вакууме (а я ещё сам не сталкивался

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

B>Мне всегда было не ясно, что же такое это интеллектуальное кэширование и чем оно лучше, чем кэширование записей (читай, сущностей) в РСУДБ ?

О, это отдельный долгий разговор. Вкратце — в ООСУБД метаинформация намного более подробная, что приводит к увеличению возможностей по оптимизации.

... << RSDN@Home 1.1.4 beta 3 rev. 248>>

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

AVK>Еще раз — ты путаешь реляционные СУБД в их современном виде и реляционную структуру как принцип. Современные РСУБД в качестве аргумента реляции используют наиболее примитивную структуру из возможных — плоский список. Отсюда и проблемы с хранением объектов. Уже в XML с этим проблем на порядок меньше.
Не совсем понимаю. Дайте ссылку куда-нить, а то не пойму ничего никак.

AVK>Отнюдь. Если выкинуть иерархические фишки, то отличие между XPath и SQL минимально.
Нда. Вот только иерархическую сущность выкинуть непросто.

AVK>Нет. Навигация предполагает наличие курсора, а его в XPath нет. Путь в нем по сути аналогичен имени таблицы в SQL.
Пожалйста, ссылку на источник такого определения, если можно. Тут возможно путаница между навигационными и сетевыми БД. Прошу прощения, если не совсем владею терминологией.

B>> Само название XPATH уже о многом говорит.

AVK>О чем?
О ПУТИ по которому нужно добираться до объекта.

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

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

Какую ссылку? На то что объектные графы плохо ложаться на плоские таблицы? Или о чем ты?

AVK>>Отнюдь. Если выкинуть иерархические фишки, то отличие между XPath и SQL минимально.
B>Нда. Вот только иерархическую сущность выкинуть непросто.

Это уже неважно. Главное — XPath по сути тот же SQL для иерархических данных.

AVK>>Нет. Навигация предполагает наличие курсора, а его в XPath нет. Путь в нем по сути аналогичен имени таблицы в SQL.
B>Пожалйста, ссылку на источник такого определения, если можно.

Это не определение.

B>>> Само название XPATH уже о многом говорит.

AVK>>О чем?
B>О ПУТИ по которому нужно добираться до объекта.

Неа. По путям XPath нельзя добраться до объекта! Это лишь указание где искать. Более того — в XPath не существует типа данных, представляющего единичный объект. Единственный непримитивный тип это node set, набор(!) узлов. Но даже node set получается не только по пути, но и по условию. К примеру такой запрос SQL:

select a1 from some_place where a2=3

Будет иметь отдаленным аналогом такой запрос XPath

some_place[@a2=3]/@a1

Синтаксис другой, суть та же. Понятно что таких аналогий для более сложных конструкций найти не так просто, но речь не об этом, а о том что подход, выражающийся в работе с наборами данных и их взаимодействиями применим и над иерархическими структурами. И проблема с объектами не в принципах, а в том что плоские структуры таблиц для этого плохо подходят. Уже переход на иерархические структуры заметно все упрощает, хотя в идеале конечно СУБД должна управлять графами. Увы, современное состояние IT пока не предлагает эффективных БД сетевой структуры.

... << RSDN@Home 1.1.4 beta 3 rev. 248>>

Здравствуйте, Сергей Губанов, Вы писали:

почитай, например, реляционную алгебру и ты начнешь понимать, что же людям может быть нужно от OOБД...

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

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

_MM_>Здравствуйте, Сергей Губанов, Вы писали:

_MM_>почитай, например, реляционную алгебру и ты начнешь понимать, что же людям может быть нужно от OOБД...

Реляционная алгебра мне известна.

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

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

B>>Мне всегда было не ясно, что же такое это интеллектуальное кэширование и чем оно лучше, чем кэширование записей (читай, сущностей) в РСУДБ ?

AVK>О, это отдельный долгий разговор. Вкратце — в ООСУБД метаинформация намного более подробная, что приводит к увеличению возможностей по оптимизации.
Не согласен.

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

AVK>>О, это отдельный долгий разговор. Вкратце — в ООСУБД метаинформация намного более подробная, что приводит к увеличению возможностей по оптимизации.
GZ>Не согласен.

... << RSDN@Home 1.1.4 beta 3 rev. 248>>

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

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

AVK>>>О, это отдельный долгий разговор. Вкратце — в ООСУБД метаинформация намного более подробная, что приводит к увеличению возможностей по оптимизации.
GZ>>Не согласен.

В РСУБД есть информация о хранении. В ООСУБД из-за того, что присутствует поведение объектов, прогнозировать выполнение на основе этих данных невозможно. Соответсвенно, возможности по оптимизации не увеличиваются, а становятся чисто эвристическими (и не всегда самыми оптимальными).

AVK>Не забывай про контекст — оптимизации кеширования, а не оптимизации вобще.
К большому сожалению, именно о ней и говорится.
1. Если обращение происходит только к внутренним данным объекта, то все нормально, и все как в РСУБД c их кортежами и экстентами.
2. Для сторед процедур можно построить и сохранить планы выполнения. Если запрошена проперть у ООСУБД, нельзя точно спрогнозировать что она для себя потребует в процессе выполнения. Внутренняя логика метода, со всеми if'ами и switch'ами, наследованием, перекрестными вызовами, может быть достаточно сложна для этого. Для этого отслеживают статистику, что было запрошено при выполнении этой проперти в прошлые разы. Но вполне понятно, что при редком попадании в какой-то if, вся эта стстистика летит насмарку.
Потому и называется интелектуальной, потому что реализовать простыми способами невозможно. Одна из фич, за которую критикуют ООСУБД.
С уважением, Gleb.

Mr. None -> Re[6]: Границы применимости парадигм программирования

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

Хм... это и perl может

Posted via RSDN NNTP Server 1.9 delta

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

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

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

AVK>>>Нет. Навигация предполагает наличие курсора, а его в XPath нет. Путь в нем по сути аналогичен имени таблицы в SQL.
B>>Пожалйста, ссылку на источник такого определения, если можно.
AVK>Это не определение.
Ээээ... опять прошу прощения за непонятность. Где указано, что навигация предполагает наличие курсора? Опять же, я не знаком с таким вопросом.

AVK>Неа. По путям XPath нельзя добраться до объекта! Это лишь указание где искать. Более того — в XPath не существует типа данных, представляющего единичный объект. Единственный непримитивный тип это node set, набор(!) узлов. Но даже node set получается не только по пути, но и по условию. К примеру такой запрос SQL:
AVK>

AVK>select a1 from some_place where a2=3
AVK>

AVK>Будет иметь отдаленным аналогом такой запрос XPath
AVK>

AVK>some_place[@a2=3]/@a1
AVK>

AVK>Синтаксис другой, суть та же. Понятно что таких аналогий для более сложных конструкций найти не так просто, но речь не об этом, а о том что подход, выражающийся в работе с наборами данных и их взаимодействиями применим и над иерархическими структурами. И проблема с объектами не в принципах, а в том что плоские структуры таблиц для этого плохо подходят. Уже переход на иерархические структуры заметно все упрощает, хотя в идеале конечно СУБД должна управлять графами. Увы, современное состояние IT пока не предлагает эффективных БД сетевой структуры.
Мне всегда казалось что проблема с сетевыми БД вовсе не в их эффективности. Если угодно, я могу написать на Питоне (на java чуть дольше, на C# тоже) сетевую БД, причем довольно быстро, и работать она будет весьма эффективно. Могу изложить основной принцип работы, если угодно. Впрочем, не претендую на профессионализм в данном вопросе, скорее всего у меня несколько дилетантский подход.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>По поводу классов

СГ>ООП заставляет программиста думать о предметной области в терминах объектов, но не классов объектов! Зачем Вам классы? Зачем Вам наследование классов? Если классификация оказывается полезной — хорошо, если классы бесполезны — тоже ничего страшного!
Все это верно, возможно я подумаю об использованиии прототипов в качестве способа создания классов и все уляжется.
СГ>По поводу ООБД

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

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

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

GZ>Аналогично, не совсем согласен с автором, особенно с Table-Oriented Programming. Еще одна грыжа, не более того.
Да, автор тоже грешит необъективностью в критике ООП. Хотя многое заставило меня задуматься — мож не стоит так сильно налегать на ООП ? Процедурные решения часто проще и понятнее.

GZ>Посмотрел www.prevayler.org, сильно не дотягивает до нормальной OOCУБД.
Да, основная трабла — принципиальное отстутсвие языка запросов. Можно прикрутить XPATH, но это мне не кажется хорошим выходом. Больше, честно говоря, не знаю, чего там не хватает. Есть какие-то конкретные идеи, чего еще не хватает ? Было бы интересно выслушать.
Но проблема была не в том, что превэйлер не дотягивает до СУБД. В некотором смысле, превэйлер — способ работать с персистентным ООП, т.е. способ работать с объектами, зная что все результаты гарантированно будут сохранены, не более того. Идея здравая. Проблемы начинаются, когда создаешь ОО модель данных. Ты просто ВЫНУЖДЕН каждый объект нумеровать или как-то еще идентифицирровать. Хранить ссылку где-то в какой-нибудь коллекции. По факту выходит еще много заморочек, к модели в общем-то не относящихся, а лишь помогающих с ней работать. Все эти заморочки можно, конечно, автоматихировать (благо, у Питона гора возможностей по поводу интроспекции), но в конечном итоге у меня создалось стойкое впечатление, что я заново изобретаю базу данных. Тогда я имел неосторожность сходить туды: http://www.geocities.com/tablizer/oopbad.htm
и слова автора по поводу reinventing database с таким резонансом отдались в моей душе, что я чуть не поплакал

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

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

GZ>PS: Существует достаточно много очень интересных парадигм, о которых все говорят и дивятся. Действительно, очень правильные вещи. Так сказать, двигают науку. Но в коммерции не проходят обычно по двум причинам. 1. Быстрота разработки. 2. Скорость выполнения. И маркетинг здесь не причем.
При чем, но это уже совсем другой вопрос.

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

AVK>>Какую ссылку? На то что объектные графы плохо ложаться на плоские таблицы? Или о чем ты?
B>Прошу прощения, не могли бы Вы объяснить более развернуто Ваше предыдущее утверждение о наиболее примитивной структуре (плоский список). Я плохо знаком с вопросом, поэтому прошу Вас дать (если возможно) какие-нибудь ссылки по этой теме.

Ты плохо знаком с РСУБД

В современной БД единственный способ представления набора данных это таблица, т.е. плоский прямоугольный список. Все остальные структуры эмулируются, из-за чего собственно и возникают проблемы.

B>>>Пожалйста, ссылку на источник такого определения, если можно.
AVK>>Это не определение.
B>Ээээ... опять прошу прощения за непонятность. Где указано, что навигация предполагает наличие курсора? Опять же, я не знаком с таким вопросом.

Курсор это текущая позиция. Навигация, насколько я понимаю русский язык, — навигация это определение позиции и направления на поверхности земли. О какой навигации может идти речь, если текущей позиции не существует?

B>Мне всегда казалось что проблема с сетевыми БД вовсе не в их эффективности.

Именно в эффективности. Ну и кардинально большей сложности все инфраструктуры. Учимтывая сложность современных оптимизаторов, боюсь даже представить сложность оптимизатора аналогичного уровня для сетевых БД.

B> Если угодно, я могу написать на Питоне (на java чуть дольше, на C# тоже) сетевую БД, причем довольно быстро, и работать она будет весьма эффективно.

Думаю ты ошибаешься

. Попробуй сравнить свою БД и промышленный sql-сервер на больших объемах и, скажем, сотне одновременнно работающих пользователей и ты все поймешь сам

. И еще провокационный вопрос — какой уровень изоляций поддерживает твоя БД и какая механика разруливания параллельного доступа используется?

B> Могу изложить основной принцип работы, если угодно.

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

... << RSDN@Home 1.1.4 beta 3 rev. 248>>

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

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

AVK>Ты плохо знаком с РСУБД

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

AVK>Курсор это текущая позиция. Навигация, насколько я понимаю русский язык, — навигация это определение позиции и направления на поверхности земли. О какой навигации может идти речь, если текущей позиции не существует?
Ладно, мы имеем в виду разные вещи. Я подразумевал навигацию по ссылкам.

AVK>Думаю ты ошибаешься

. И еще провокационный вопрос — какой уровень изоляций поддерживает твоя БД и какая механика разруливания параллельного доступа используется?
Ой, там все проще в 15 раз. Вся сеть в памяти, операции над ней предварительно сохраняются в лог транзакций. На объемах данных, меньших нескольких Гб работать будет мгновенно. Уровень изоляции не требуется, т.к. транзакции можно и в самом деле последовательно выполнять (все в памяти же...)

AVK>Не надо, я довольно неплохо знаком с современным положением дел в этой области.
Упс. не буду.

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

AVK>>Курсор это текущая позиция. Навигация, насколько я понимаю русский язык, — навигация это определение позиции и направления на поверхности земли. О какой навигации может идти речь, если текущей позиции не существует?
B>Ладно, мы имеем в виду разные вещи. Я подразумевал навигацию по ссылкам.

Навигацию по ссылкам в XPath? Теперь уже я не понимаю о чем речь.

B>Ой, там все проще в 15 раз. Вся сеть в памяти, операции над ней предварительно сохраняются в лог транзакций. На объемах данных, меньших нескольких Гб работать будет мгновенно. Уровень изоляции не требуется, т.к. транзакции можно и в самом деле последовательно выполнять (все в памяти же...)

Т.е. параллельный доступ вобще отсутствует? Мдя, после этого я бы о быстродействии даже не и заикался бы.

... << RSDN@Home 1.1.4 beta 3 rev. 248>>

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

B>А про всякое моделирование предметной области методами ООП забыть, как о страшном сне.
А каким методом моделировать предметную область лучше? Можно хотябы простейший пример, типа "Вот смотрите, имеетя предметная область. Если замоделировать ее через ОО, получится вот такая лажа, а если сделать вот так ..., то будет счастье"

... << RSDN@Home 1.1.4 @@subversion >>

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

GZ>ООСУБД содержит не только состояние объектов, но и его поведение.
Хм, а как БД может хранить поведение?

... << RSDN@Home 1.1.4 @@subversion >>

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

[skip]

Здравая мысль — ООП не универсально. Но мне не понятно откуда утверждения про реальный мир. Какие 3 кита ООП — абстракция, инкапсуляция, полиморфизм. А что есть абстракция — упрощение реального мира, построение модели. ООП работает с моделями, а не с реальным миром (как и все что связанно с разработкой ПО). Отсюда все проблемы любой парадигмы: построенная нами модель неверно или не полно описывает обьекты реального мира. И это только первая часть проблемы... Вторая часть — оценивать согласованность мира и нашей модели можем только мы сами. А если это делает чел. который эту модель и создавал, то оценка выйдет скорее всего предвзятая...

prVovik wrote:

> Здравствуйте, GlebZ, Вы писали:
>
> GZ>ООСУБД содержит не только состояние объектов, но и его поведение.
> Хм, а как БД может хранить поведение?

определение классов может быть пересено в базу

Posted via RSDN NNTP Server 1.9 delta

Здравствуйте, prVovik, Вы писали:
GZ>>ООСУБД содержит не только состояние объектов, но и его поведение.
V>Хм, а как БД может хранить поведение?
при помощи первых двух букв своей аббревиатуры.
З.Ы. современные РСУБД тоже хранят поведение. RTFM по stored procedure & trigger

... << RSDN@Home 1.1.4 beta 3 rev. 185>>

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

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

AVK>Навигацию по ссылкам в XPath? Теперь уже я не понимаю о чем речь.
В XPATH шаблон (ну или часть шаблонаб если более точно) задается ссылками. Ладно, кажется мы зашли в тупик, потому что я, похоже говорю о том, чего не очень понимаю. Не знаю я точного определения навигационной БД и сетевой БД и чем они друг от друга отличаются тоже слабо представляю. Я и просил просветить меня в этом плане.

AVK>Т.е. параллельный доступ вобще отсутствует? Мдя, после этого я бы о быстродействии даже не и заикался бы.

А вот тут уже батенька Вы говорите о том, чего не очень понимаете. Давайте на этом пока и закончим или вынесем в отдельную тему.

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

Эх.... все же не удержусь и прокомментирую.

AVK>Т.е. параллельный доступ вобще отсутствует? Мдя, после этого я бы о быстродействии даже не и заикался бы.

Внимательно надо читать www.prevazler.org.

Параллельная работа нужна тогда, когда отдельная пользовательская транзакция выполняется ОЧ долго. Это, в частности, происходит тогда, когда надо с винта читать и писать МНОГО.

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

Огромное преимущество такой организации БД — потрясающая, просто ошеломляющая скорость. Т.е. превэйлер-образная БД работает как минимум в 1000 раз быстрее, чем обычная РСУБД.

НУ есть, конечно и затыки свои (а где их нет?). Если интересно, напишу.

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

B>Параллельная работа нужна тогда, когда отдельная пользовательская транзакция выполняется ОЧ долго. Это, в частности, происходит тогда, когда надо с винта читать и писать МНОГО.

Она нужна во многих случаях. Иначе бы на это производители современных СУБД не убивали столько сил. И дело даже не столько в паралдлельной работе, сколько в обеспечении уровня изоляции.

B>В нашем случае

В вашем это каком?

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

B>Огромное преимущество такой организации БД — потрясающая, просто ошеломляющая скорость. Т.е. превэйлер-образная БД работает как минимум в 1000 раз быстрее, чем обычная РСУБД.

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

... << RSDN@Home 1.1.4 beta 3 rev. 254>>

Sinclair,

Позволю себе небольшое уточнение.

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

> И совершенно напрасно не поворачивается. JavaScript устроен именно так, только немношко побогаче. Не факт, что он есмь спасение для бизнес-задач, но это не отменяет его объектности.

Именно объектности. Объектно-ориентированным JavaScript не является. Но, естественно, не из-за того, что в нем есть упомянутая функциональность.

Posted via RSDN NNTP Server 1.9 delta

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

Извиняюсь, за задержку с ответом, очень много было работы.
S>Здравствуйте, GlebZ, Вы писали:

GZ>>2. Для сторед процедур можно построить и сохранить планы выполнения.
S>Верно, с оговорками. А как же if? а циклы?
А никак. В комерческих РСУБД важны только планы выполнения и зависимости. Или есть другие механизмы?
GZ>>Если запрошена проперть у ООСУБД, нельзя точно спрогнозировать что она для себя потребует в процессе выполнения.
S>Почему это невозможно?
GZ>>Внутренняя логика метода, со всеми if'ами и switch'ами, наследованием, перекрестными вызовами, может быть достаточно сложна для этого.
S>Хм. На первый взгляд, ничего сверхъестественного.
С вашим подходом, возможно. У меня была задумка сделать все без зависимости от языка программирования. И MSIL тогда был только в проекте.
GZ>> Для этого отслеживают статистику, что было запрошено при выполнении этой проперти в прошлые разы.
S>А это кто например? Можно ссылку на ООСУБД, которая это умеет?
Источник, какая-то книга по теории баз данных. Точно сказать не могу (давно этим увлекался), возможно даже Дейт.
Система, остлеживает выполнение, и по мере накопления статистики строит или перестраивает планы. То есть, пытается делать то же самое что в РСУБД. Вы похоже пошли значительно дальше.

S>Уже сейчас очевидно, что далеко не во всех случаях можно будет получить 100% оптимальный план запроса. Основные заметные препятствия — рекурсия/циклы и исключения.
S>То есть вряд ли удастся привести предикат вида
S>

S>Factorial(self.Salary)<120
S>

S>к предикату вида
S>

S>self._salary < 5
S>

S>А это, в свою очередь, не даст использовать индекс. Но лично мне греет душу смутное ощущение, что факториалы применяются в реальном софте, ворочающем гигабайтами, очень редко. И что в практических случаях из запроса удастся выделить предикат, достаточно селективный для того, чтобы снизить стоимость выполнения запроса до приемлемой.

S>Ну вот С++ тоже далеко не всегда может вполнить инлайнинг; тем не менее, его включение во многих случаях приводит к заметному росту производительности. Например, насколько мне известно, STL весьма чувствителен к поддержке инлайнинга, т.к. его применение очень много где из кучи взаимных вызовов и проверок сворачивается, грубо говоря, в rep stosd.

Круто. Где-то это я уже читал и тогда мне это не понравилось. Но сейчас весьма круто. Тогда не особо поверилось, что такое возможно (грешен, субъективен, не особо понимал вся прелесть байт-кода). Во многих случаях получить селективный предикат будет невозможно. По крайней мере, как это сделать с рекурсией я не догадался. Я бы еще прибавил ограничение — если существует 3 различных переменные в одном составном операторе, позднее связывание. Процентов 80-90 пропертей достаточны элементарны и данный метод их сократить. Правда при этом нужно будет реализовывать вычисление всего что можно предварительно вычислить (что мне кажется очень полезной но несколько сложноватой задачей, хотя и не невозможной).

С уважением, Gleb.

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

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

B>>Параллельная работа нужна тогда, когда отдельная пользовательская транзакция выполняется ОЧ долго. Это, в частности, происходит тогда, когда надо с винта читать и писать МНОГО.
AVK>Она нужна во многих случаях. Иначе бы на это производители современных СУБД не убивали столько сил. И дело даже не столько в паралдлельной работе, сколько в обеспечении уровня изоляции.
Уровни изоляции нужны для того, чтобы симулировать последовательное выполнение транзакций в системе, где транзакции проходят параллельно. Самый лучший уровень изоляции — SERIALIZED, т.е. когда выполнение транзакций неотличимо от последовательного. Все остальные уровни изоляции — компромисс между скоростью и надежностью. Когда транзакции НА САМОМ ДЕЛЕ идут последовательно, все эти заморочки не нужны.

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

К тому же, за все надо платить.
Одно из действительно неприятных (ну, по крайней мере, очень непривычных) свойств таких бд состоит в том, что запросы в БД по сути являются частью БД и имеют над ней полную власть. Т.е. надо очень хорошо думать, какие запросы писать — а то порушить можно все за считанные микросекунды

. Выражаясь словами изобретателей концепции, Вы больше не пишете клиентский код. Вы тепер ьпишете серверный код и должны точно знать, что делаете.

Второе неприятное свойство таких БД (я уже по-моему, говорил) — нет языка запросов в принципе. Можно, конечно, прикрутить XPATH и это решит проблему.

Третья неприятность (назвать ее свойством БД я не могу, очень уж субъективно это) состоит в том, что вот лично я по факту не смог представить себе гибкой ООП модели своей предметной области (учет кредитов в банке). Может быть, prototype-based OOП поможет. Не знаю. Может быть это просто груз моего старого опыта с РСУБД давит.

Ну еще есть куча заморочек, связанных с ООБД вообще. Например, привязка к конкретному языку.

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

AVK>>На игрушечных задачах. Пойми, длительность транзакции определяется предметной областью, а не разработчиком БД.
B>Можно ли назвать игрушучной задачу, которая работает со сложной структурой данных, занимающей до 1Гб ?

Можно. 1Гб по нынешним временам детский объем, так что это не показатель (у януса примерно такой порядок БД, а там банальный джет). Тяжесть задач выражается не столько в сложных структурах данных, сколько в требованиях по скорости реакции, способности выполнять сложные выборки, обслуживать десятки и сотни запросов одновременно, при том что единичная транзакция может быть довольно длительной. А если у тебя десяток пользователей, то конечно можно и отказаться от параллельного выполнения.

B> У меня язык не поворачивается. Есть у меня такая задача, написанная под РСУБД — так запросы там очень не быстро ворочаются.

А сколько клиентов одновременно работают с базой?

B>Одно из действительно неприятных (ну, по крайней мере, очень непривычных) свойств таких бд состоит в том, что запросы в БД по сути являются частью БД и имеют над ней полную власть. Т.е. надо очень хорошо думать, какие запросы писать — а то порушить можно все за считанные микросекунды

.

При современных требованиях звучит как приговор.

... << RSDN@Home 1.1.4 beta 3 rev. 254>>

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

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

GZ>>Аналогично, не совсем согласен с автором, особенно с Table-Oriented Programming. Еще одна грыжа, не более того.
B>Да, автор тоже грешит необъективностью в критике ООП. Хотя многое заставило меня задуматься — мож не стоит так сильно налегать на ООП ? Процедурные решения часто проще и понятнее.
Если у тебя написано кода на пол-гига и с ним работает человек двадцать, то о процедурном решении можно забыть.

GZ>>Посмотрел www.prevayler.org, сильно не дотягивает до нормальной OOCУБД.
B>Да, основная трабла — принципиальное отстутсвие языка запросов. Можно прикрутить XPATH, но это мне не кажется хорошим выходом. Больше, честно говоря, не знаю, чего там не хватает. Есть какие-то конкретные идеи, чего еще не хватает ? Было бы интересно выслушать.
B>Но проблема была не в том, что превэйлер не дотягивает до СУБД. В некотором смысле, превэйлер — способ работать с персистентным ООП, т.е. способ работать с объектами, зная что все результаты гарантированно будут сохранены, не более того. Идея здравая. Проблемы начинаются, когда создаешь ОО модель данных. Ты просто ВЫНУЖДЕН каждый объект нумеровать или как-то еще идентифицирровать. Хранить ссылку где-то в какой-нибудь коллекции. По факту выходит еще много заморочек, к модели в общем-то не относящихся, а лишь помогающих с ней работать. Все эти заморочки можно, конечно, автоматихировать (благо, у Питона гора возможностей по поводу интроспекции), но в конечном итоге у меня создалось стойкое впечатление, что я заново изобретаю базу данных. Тогда я имел неосторожность сходить туды: http://www.geocities.com/tablizer/oopbad.htm
B>и слова автора по поводу reinventing database с таким резонансом отдались в моей душе, что я чуть не поплакал

Вы наткнулись как раз на то, что ООСУБД, просто обязана делать, а именно иметь язык запросов. То что можно обойтись просто навигационным доступом это миф, я сам на это как-то наткнулся. Насчет хранении ссылки, то здесь все верно, если время жизни объекта зависит от существовании ссылки. При правильном подходе, эту методику можно очень красиво использовать. В действительности, еще хотелось бы иметь классификацию ссылок, и определение логически удаленного объекта.
Еще хотелось бы сказать об OID и почему я назвал его наиболее ценным в концепции OID. (Ессно мое субъективное мнение)
1. Не стоит его сравнивать с ассоциативным доступом в РСУБД. OID не является ключом к объекту. Скорее он похож на указатель. То есть, для того, чтобы получить доступ к объекту не надо искать его в индексе, как это сделано в РСУБД. За счет этого, утверждается, что для распределенных (сильно нормализованных) объектов, объектно-ориентированные СУБД работают значительно быстрее.
2. Формально (насколько я помню манифест ООБД) OID является просто идентификатором. Фактически это путь к объекту, то есть СЕРВЕР.БАЗА.ТИП.ОБЪЕКТ (по крайней мере, он должен быть таким, хотя бы на уровне логического OID). Таким образом, имея идентификатор, можно забыть о том, где находится объект. У тебя есть только система, и OID. Это вполне достаточно для его получения, независимо от того, где он находится в системе (на каком сервере, в какой БД и независимо от типа).
3. Насчет идентификации через OID. Согласно манифесту OID идентифицирует объект как во время его жизни, так и после. То есть, не может существовать два одинаковых OID. Для РСУБД это нормальная ситуация, и очень забавно смотреть, что когда продукт вырастает до распределенного, народ начинает придумывать дополнительные, глобально уникальные, ключи или процедуры маршализации.
4. OID может сразу содержать тип объекта. Таким образом, если у объекта есть ссылка на другой объект, то этот другой объект, не обязательно должен быть одного предопределенного типа или наследоваться от него. Безусловно, некоторая логика должна ограничивать возможный тип объекта, но радует сам факт. (При доступе по ключу, в РСУБД, это нормальная ситуация, для ООП нет). Когда-то, когда я интересовался этим вопросом, сделал прототипчик. Методика работала на ура.

GZ>>Тяжело описать просто то, что в реальном мире сложно устроено. Не надо, это перекладывать на недостатки метода.
B>Верно, однако обратите внимание на такой момент. Методология вряд ли сделает вещи проще. Но одни методологии (в отличие от других) ДОБАВЯТ сложности, как это часто бывает.
Я бы сказал не сложности, а количества выполняемой работы. Как сказал Черчиль: "Демократия очень плохой способ управления государством, но я не знаю лучшей альтернативы"(дословно не помню, написал по смыслу). Методология проектирования (RUP, MSF), обычно утверждает, что определив свойства и действия, мы можем определить используемые объекты. Точно-так же как и реале. Человеческий мозг идентифицирует объекты по свойствам. Например: пиво — бутылка, темная жидкость с пузырьками, его можно пить, на нем написано "ПИВО" и т.д. и т.п. Подобных свойств или признаков, очень много, чтобы человек мог идентифицировать, что это есть пиво. В программировании, мы всегда описываем только те свойства, которые нам нужны. Поэтому, в жизни сложность объекта в значительной степени выше, чем мы используем. Новые свойства добавить не сложно, если бы не одно но. Человеку свойственно лениться и делать ошибки. Для того, чтобы реализовать свойство, они выделяются в отдельные объект и привязывается к различным типам объектов. В результате, меньше работы, и меньшая вероятность копирования ошибок. Плата за это — неясность является свойство для данного объекта, абсолютно точно таким, как и для другого объекта. То есть, это уже меньше похоже на реал, но действительно сокращает количество работы и весьма возможно получить проблемы при использовании. ООП, или компоненты, все таки очень похожи на объекты в жизни, но не одинаковы, поскольку сильно упрощены. А теперь, представь себе, как это все описать в процедурном программировании? И в особенности если в программе должны ориентироваться n количество программистов. ООП и компоненты дают описание самой программы и действий в единых терминах как для пользователя так и для программиста. С процедурным программирование, это сделать значительно сложнее.

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

B>Вот вот, именно это я имел в виду. Вообще применять ООП внутри компонент и только для внутренних нужд. А про всякое моделирование предметной области методами ООП забыть, как о страшном сне.
А можно спросить, в чем разница в моделировании предметной области методами ООП и компонент? Мне кажется, что компонент. программирование, — ограниченное применение ООП. Разница — только в системе публикации интерфейса.

С уважением, Gleb.

	От:	Borisman2
	Дата:	04.12.04 08:29
	Оценка:	104 (7) +1

	От:	GlebZ
	Дата:	06.12.04 18:55
	Оценка:	36 (2)

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	06.12.04 10:15
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	07.12.04 05:12
Оценка:	+2

	От:	Borisman2
	Дата:	07.12.04 05:13
	Оценка:	12 (1)

От:	Mr. None	http://mrnone.blogspot.com
Дата:	06.12.04 05:46
Оценка:	1 (1)

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	05.12.04 10:02
Оценка:	+1

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	08.12.04 12:18
Оценка:

От:	_vovin	http://www.pragmatic-architect.com
Дата:	08.12.04 15:15
Оценка:

	От:	Павел Кузнецов
	Дата:	09.12.04 18:22
	Оценка: