Здравствуйте, Voblin, Вы писали:
V>Шаблоны — это всего лишь умные макросы. С логической точки зрения это безразлично — использовать template или копирование/вставку+поиск/замену. С макросоми, конечно, продуктивнее. Да и ошибки исправлять проще.
Язык высокорого уровня — это тоже лишь набор макросов
A>Если же рассматривать, почему: Вы подобрали плохой пример — здесь удобнее не наследование, а включение. A>Так, "Персона" имеет необязательное свойство "Пол". Это удобнее, и не надо вводить спорную концепцию. V>С полом, конечно, пример не совсем удачный. Хотя всяко может быть. Особенно, если CFemale реализует женскую логику
V>Более удачный пример — Контрагент — (физ/юр) лицо. Это действительно разные классы, каждый из которых обладает своим набором атрибутов (даже длина поля ИНН разная).
Где Вы видели мутирующих контрагентов?
Тут скорее подходит принцип "актуализации".
Здравствуйте, Akzhan, Вы писали:
V>Шаблоны — это всего лишь умные макросы. С логической точки зрения это безразлично — использовать template или копирование/вставку+поиск/замену. С макросоми, конечно, продуктивнее. Да и ошибки исправлять проще.
A>Язык высокорого уровня — это тоже лишь набор макросов
Конечно. Но не в такой же степени!!!
A>Если же рассматривать, почему: Вы подобрали плохой пример — здесь удобнее не наследование, а включение. A>Так, "Персона" имеет необязательное свойство "Пол". Это удобнее, и не надо вводить спорную концепцию. V>С полом, конечно, пример не совсем удачный. Хотя всяко может быть. Особенно, если CFemale реализует женскую логику
V>Более удачный пример — Контрагент — (физ/юр) лицо. Это действительно разные классы, каждый из которых обладает своим набором атрибутов (даже длина поля ИНН разная).
A>Где Вы видели мутирующих контрагентов? A>Тут скорее подходит принцип "актуализации".
Запросто! Даже предложу два логических уровня.
1. Уровень бизнес-логики. Был контрагент покупателем, стал контрагент поставщиком. Был контрагент физ. лицом, а потом взял, и оформился в юр. лицо. Если с точки зрения бух. учёта это уже совсем другой контрагент, то в управленческом учёте это должен быть тот же самый. Нам же интересны реалиные взаиморасчёты, накопительные скидки и пр.
2. Уровень софтинки. Когда юзер давит кнопку "создать контрагента", перед ним возникает окошечко, в котором он заполнит его карточку. По умолчанию, допустим, контрагент создаётся как юр. лицо (так захотели пользователи). Соответственно, на формочке (и в том объекте, который за ней стоит) есть поля Name, FullName, VATRegNo (ИНН), RegNo (номер гос. регистрации), Юр. адрес и т.д.. Юзер перещёлкивает крыжик с юр. на физ. лицо, и эти поля (может быть, за исключением ИНН) исчезают, и появляются FirstName, LastName и т.д. Логично?
Можно, конечно, сделать как в 1С — в объекте Контрагент есть все поля, характеризующие и юр. и физ. лицо. Мне это не нравится. Я старый маразматичный поклонник нормализованных баз.
Такие тексты очень сложно воспринимать в отрыве от контекста.
Что это за проект? На какой он стадии? Кем проводится? Какие ресурсы задействованы? Что предполагается: проприетарный или свободный софт? И ещё много вопросов.
И ещё хочу предостеречь о двух вещах:
1. Архитектура "Толстый клиент на ЯВУ — SQL БД, спроектированная вручную" — одна из самых распространённых ошибок. Независимо от от того, есть ли между ними прослойка (или даже две). Это прям какой-то интеллектуальный вирус! Если бы я был юдофобом, то заподозрил бы жидомасонский заговор. Типичный жизненный цикл таких систем:
— "Какие классные, мощные, продвинутые инструменты! Сколько литературы! Как всё стройно, логично и правильно!" Есть заказчик (как правило, "наша фирма"), готовый финансировать разработку.
— Обследуем предметную область, пишем что-то вроде ТЗ. Попутно придумываем несколько "супер-пупер" технологических решений, которые позволят больше никогда не задумываться о иерархиях/историях значений/скорости получения итогов/проектировании формочек (нужное подчеркнуть и/или добавить своё)
— Проектируем БД в ERWin, пишем доп. компоненты к любимому средству разработки. Попутно постигаем ERP, SCM, CRM, ABC-анализ. Ой, прошёл год.
— Пишем клиента. В системе уже сотни классов, десятки форм, много печатных форм. Коллектив разработчиков — большой и дружный. Прошёл ещё год.
— Системой уже можно гордиться.
— Показали главбуху. главбух несёт какую-то чушь. Показали манагерам. Манагеры придираются по ерунде. Доделываем.
— Доделываем — показываем — доделываем — показываем — доделываем — показываем. Прошёл ещё год.
— Внедряем! Мучительно, на нервах, но система работает!
— А не продать ли нам её кому-нибудь ещё? Денег заработаем гору! Ищем клиента, находим, беседуем. Блин! Да нужно много чего под него переделать. Причём в модулях, про которые уже никто ничего не помнит. Либо отказываемся от проекта, либо берёмся за него и проваливаем.
— Изменилось законодательство. Ё моё! Всё надо переделать!
— Директор — козёл. Вместо нашей системы решил ставить 1С. 1С — отстой!
— У нас внедряют 1С. Сваливаем.
2. Бизнес-софт обязан соответствовать законодательству. Вы ничего не сможете продать оптом, но напечатав счёт-фактуру (в которой указывается ГТД, правильно рассчитанный НДС, НП, акциз...), не сможете ничего оплатить по банку, но напечатав платёжку, разграфлённую с точностью до милиметра. А законодательство меняется с ураганной скоростью. Притом, как правило, в сторону усложнения и увеличения числа противоречий. Почитайте налоговый кодекс и последние ПБУ. Мало не покажется. Только свяжитесь с бухгалтерией, и никаких сил на ERP, SCM, CRM и ABC-анализ уже не останется.
Такова жизнь.
Не обижайтесь.
Re[11]: Шаблоны - не выход. Вернее, не всегда выход.
Здравствуйте, Voblin, Вы писали:
A>Где Вы видели мутирующих контрагентов? A>Тут скорее подходит принцип "актуализации". V>Запросто! Даже предложу два логических уровня. V>1. Уровень бизнес-логики. Был контрагент покупателем, стал контрагент поставщиком. Был контрагент физ. лицом, а потом взял, и оформился в юр. лицо. Если с точки зрения бух. учёта это уже совсем другой контрагент, то в управленческом учёте это должен быть тот же самый. Нам же интересны реалиные взаиморасчёты, накопительные скидки и пр.
Тут же напрашивается решение с разделением понятий "Контрагент" и "Учётные данные контрагента". У нас клиенты могут иметь множество юридических лиц, например. А группы скидок могут присваиваться на любом уровне (от клиента до конкретного счёта).
V>Помнится, как-то в таблице, хранящей справочник товаров системы Navision Attain я насчитал 130 полей. Каково, а?
Не будем ругать то, что работает
A>Я сейчас пишу статью на эту тему. Можете посмотреть драфт: http://www.akzhan.midi.ru/devcorner/articles/YourIS-IronBeans.html V>Такие тексты очень сложно воспринимать в отрыве от контекста. V>Что это за проект? На какой он стадии? Кем проводится? Какие ресурсы задействованы? Что предполагается: проприетарный или свободный софт? И ещё много вопросов.
Есть две системы, уже работающие по этих принципам. А сейчас выкладываю мысли в свободный доступ — наряду с демо-реализацией. В порядке обмена опытом.
V>И ещё хочу предостеречь о двух вещах: V>1. Архитектура "Толстый клиент на ЯВУ — SQL БД, спроектированная вручную" — одна из самых распространённых ошибок. Независимо от от того, есть ли между ними прослойка (или даже две). Это прям какой-то интеллектуальный вирус! Если бы я был юдофобом, то заподозрил бы жидомасонский заговор. Типичный жизненный цикл таких систем:
Знакомая история.
Тут главное вовремя остановиться с реализацией великих идей.
Кстати, в Питере есть несколько очень даже неплохих проприетарных решений, выросших до уровня коммерческих.
Здравствуйте, Voblin, Вы писали:
V>Может быть, кому-нибудь будет интересно. V>http://voblin.nm.ru/objects_classes.dhtml V>Сразу вопрос: стоит ли это опубликовать в RSDN?
Кстати, если дополните Вашу статью описанием mixin-подхода, то цены Вам не будет. Обязуюсь в таком случае выложить такой вариант у себя и даже раскрутить (включая offline-публикации).
Здравствуйте, Akzhan, Вы писали:
A>Здравствуйте, Voblin, Вы писали:
V>Может быть, кому-нибудь будет интересно. V>http://voblin.nm.ru/objects_classes.dhtml V>Сразу вопрос: стоит ли это опубликовать в RSDN?
A>Кстати, если дополните Вашу статью описанием mixin-подхода, то цены Вам не будет. Обязуюсь в таком случае выложить такой вариант у себя и даже раскрутить (включая offline-публикации).
ОК. Сделаю. Только возьму тайм-аут на недельку, а то начальство с потрохами сожрёт.
Re[12]: Шаблоны - не выход. Вернее, не всегда выход.
Здравствуйте, Akzhan, Вы писали:
V>Помнится, как-то в таблице, хранящей справочник товаров системы Navision Attain я насчитал 130 полей. Каково, а? A>Не будем ругать то, что работает
Иногда рука сама тянется к канделябру.
A>Я сейчас пишу статью на эту тему. Можете посмотреть драфт: http://www.akzhan.midi.ru/devcorner/articles/YourIS-IronBeans.html V>Такие тексты очень сложно воспринимать в отрыве от контекста. V>Что это за проект? На какой он стадии? Кем проводится? Какие ресурсы задействованы? Что предполагается: проприетарный или свободный софт? И ещё много вопросов.
A>Есть две системы, уже работающие по этих принципам. А сейчас выкладываю мысли в свободный доступ — наряду с демо-реализацией. В порядке обмена опытом.
Это уже интересно. Особенно в свете возможной кончины 1С. Очень остро возникнет проблема — чем заткнуть дыру?
V>И ещё хочу предостеречь о двух вещах: V>1. Архитектура "Толстый клиент на ЯВУ — SQL БД, спроектированная вручную" — одна из самых распространённых ошибок. Независимо от от того, есть ли между ними прослойка (или даже две). Это прям какой-то интеллектуальный вирус! Если бы я был юдофобом, то заподозрил бы жидомасонский заговор. Типичный жизненный цикл таких систем:
A> A>Знакомая история. A>Тут главное вовремя остановиться с реализацией великих идей.
A>Кстати, в Питере есть несколько очень даже неплохих проприетарных решений, выросших до уровня коммерческих.
Всяко бывает. Не спорю.
На мой взгляд, в этом деле конструкторы типа 1С, Attain, Axapta и иже с ними перспективнее. Работает, конечно, не так быстро, зато подгонять под клиента и развивать проще.
Re[3]: Статья про развитие идей ООП. Жду комментариев.
Здравствуйте, Voblin, Вы писали:
V>Видимо Вы имеете в виду множественное наследование. У меня речь о другом.
Да, именно его я имею в виду. Я не понимаю разницы между классическим множественным наследованием и тем, что предлагается. V>У меня классы Ibo и IboSon будут идентичны. S>>Так что на диаграмме надо бы стереть слова "Non-classic". S>>Ага, дальше мы собрались отказаться от наследования и вместо "реального" класса XY: public X, Y {} ввести виртуальный класс XY. Пардон, а чем он так радикально отличается от своего "реального" тезки? V>Хорошо. По порядку. Реальный класс должен быть объявлен как положено, и экземпляры мы порождаем уже от него. V>Виртуальный же тем и виртуален, что он нигде не объявлен. Мы порождаем объект от двух классов и считаем, что теперь он принадлежит трём классам — двум реальным и одному виртуальному. Для виртуального мы тоже можем определять свойства и методы. В этом случае он станет более реальным, но всё равно у него останется налёт виртуальности: порождая экземпляр классов X,Y,Z получим экземпляр, одновременно принадлежащий классам X,Y,Z,XY,XZ,YZ,XYZ из которых первые три — реальные, последний — под вопросом, а остальные — виртуальные.
А, ну вот что-то вырисовывается. Ценность этого пока сомнительна, но по крайней мере это уже не классика. В плюсах можно вручную сделать класс XYZ потомком XY, XZ, и YZ, но, естественно, автоматически это не гарантируется.
V>В примере с clPersistent, clClient и clOrder мне нужно было показать, как мы можем добиться полиморфизма без использования наследования. По-моему, мне это удалось.
Вы просто назвали наследование по-другому. Вы собираетесь писать код, который имеет ровно ту же семантику, что и приведенный мной код на плюсах.
V>Согласен, что надо давать больше контроля. Например так, как это сделано в CLOS — вызов всех подходящих методов производится упорядоченно и программисту даётся возможность повлиять на этот порядок с помощью оператора call_next_method. Сейчас понятно, что здесь есть над чем подумать.
V>Не согласен. Это одна из основных проблем и одна из основных причин появления ООБД. V>РСУБД основаны на реляционной алгебре, которая в свою очередь основана на математической теории множеств, а ООП — вообще на чём основано. Когда это пытаешься склеивать, возникают противоречия.
Да нет там никаких противоречий. Ну где вы их увидели? Проблема — исключительно в производительности. Для реляционных СУБД просто разработаны хорошие методы оптимизации. Которые основаны на знаниях об эквивалентности планов, и методах предсказания затрат. Сегодняшнее ООП является преимущественно процедурным. Кроме того, концепции инкапсуляции и полиморфизма стимулируют нас рассматривать каждый объект как черный ящик. Это означает, что мы не можем с легкостью фокусника заменить нудный вызов метода М для всех миллионов объектов похожего класса обращением в список объектов, у которых этот вызов даст требуемый результат.
А просто отобразить поля объекта в поля таблиц базы данных — как два пальца об асфальт.
V>Готов спорить до хрипоты. В грамотно построенной логически целостной системе должен использоваться только один способ отображения. Всё остальное — кустарщина и дилетантизм. Кроме того, очень много систем автоматически строят структуру БД и структуру классов на базе метаданных. Замечательно. А про оптимизацию производительности мы просто забудем? Есть N семантически эквивалентных способов отобразить заданную иерархию классов в РСУБД. Каждый из них дает различное быстродействие при выполнении различных запросов. Но умоляю, давайте не будем здесь обсуждать эту тему! Лучше отдельный флейм начать.
V>Очень экзотический случай. Уверен, что ни одна их существующих сейчас РСУБД такое не поддерживает. Может быть, в Yukon что-то такое будет? V>Конечно, и сейчас можно в MS SQL 2000 использовать user-defined функции, но это всегда работает очень медленно именно из-за того, что не удаётся оптимизировать план выполнения запроса. Здесь я имею в виду те функции, которые не "Inline Table-valued Functions".
Ну еще бы РСУБД поддерживали объектные запросы! Это не экзотический случай, это типичная задачка, выраженная в терминах ООП. Просто обычно как раз такие задачи решают средствами РСУБД, а там наследованием и полиморфизмом даже не припахивает. Потому сразу делают всё класса XYZ, вместо метода M() у нас — поле М, и все работает и все довольны. Вот это — проблема! А отображение классов в табличку... Может, я чего-то не понимаю? Это рутина.
V>Поправлю: один класс — одна табличка. В статье я специально оговорился про подчинённые таблички.
Э, нет. Вы в самом начале отказались от того, чтобы объекты имели класс. Они у вас принадлежат произвольному множеству классов, причем это индивидуально контролируется на уровне каждого объекта. Помните? Вот у нас есть три реальных класса X, Y, Z. Еще четыре штуки виртуальных. И объекты, принадлежащие всем восьми комбинациям (включая пустую) зараз. Ну и по каким табличкам мы все это раскладываем? А, ну да. Вот теперь мы получили проблему.
V>1. Отказ от наследования — это не отличие?
У вас нет никакого отказа от наследования. Оно торчит из статьи, как кроличьи уши из шляпы. Или вы называете принудительное добавление классов-предков к классу объекта отказом от наследования? Да тут больше наследования, чем в классике! Раньше наш XYZ спокойно наследовался от XY, и горя себе не знал. A тут ему говорят, что его дядя XZ и тетя YZ теперь тоже его родители, и жить будем все вместе. И объясняют это отказом от наследования.
V>2. Проблема неопределённости последовательности вызовов решаема. Например так, как я написал выше. Или даже как-нибудь более элегантно.
В вашем объяснении выше не сказано, в каком порядке будут вызываться методы. А рассуждения в статье насчет параллельного выполнения — вообще ужасны. В каком состоянии находится ваш объект в процессе выполнения метода? Как вы собираетесь гарантировать его целостность в этом случае?
... << RSDN@Home 1.0 beta 6a >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Статья про развитие идей ООП. Жду комментариев.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Voblin, Вы писали:
V>>Видимо Вы имеете в виду множественное наследование. У меня речь о другом. S>Да, именно его я имею в виду. Я не понимаю разницы между классическим множественным наследованием и тем, что предлагается.
Конечно, каждое сочетание классов "наследует" свойства и методы всех своих подмножеств. Т.е. XY наследует всё и от Х, и от Y. Только вор в системе нет такого класса — XY. Есть объекты, принадлежащие и X, и Y (и, возможно, куче всего другого дополнительно), но класса такого нет. Итак, кто у кого что наследует? Класс XY у классов X и Y? Нет такого класса — XY! Есть объекты A(X), B(Y), C(XY), D(XYZ), которые получают свойства, методы и реализации методов классов X, Y и XY. Но это же не наследование, когда от класса к экземпляру! Наследование — это когда от класса к классу! Семантически в результате может получиться похоже, но... может и не получиться.
V>>В примере с clPersistent, clClient и clOrder мне нужно было показать, как мы можем добиться полиморфизма без использования наследования. По-моему, мне это удалось. S>Вы просто назвали наследование по-другому. Вы собираетесь писать код, который имеет ровно ту же семантику, что и приведенный мной код на плюсах.
Повторяю, что в примере с clPersistent, clClient и clOrder я действительно показал семантику, эквивалентную обычному наследованию. Если бы я взялся усложнять пример, то мог бы получить совсем другую семантику. Например, так:
Добавляем в систему класс clVendor. Предположим, в системе возможны клиенты, также являющиеся поставщиками, т.е. сочетание (clClient, clVendor, ...) является допустимым. Теперь для некоего объекта AOrder нам приспичело узнать состояние взаиморасчётов (суммарные, кредиторка и дебиторка) с тем товарисчем, который указан в поле "ClientID". Делаем это так:
var AClient as (clPersistent, clClient), Balance as Double;
AClient.LoadObject(AOrder.ClientID); // Этот метод класа clPersistent процедура загружает объект целиком.
// Т.е. сначала выясняет по идентификатору его классовую сущность, мутирует его до нужного состояния
// и вызывает свой собственный жутко полиморфный Read().
Balance = AClient.ClientBalance;
ifcast AClient as clVendor { // А не поставщик ли он ещё?
Balance -= AClient.VendorBalance; // Ага, поставщик. Вычтем свой долг перед ним.
}
if Balance + AOrder.TotAmount > 1000000 {
App.MsgBox("Только по предоплате!!!");
}
Здесь интересно то, что метод clPersistent::Read() загрузит из БД всё что необходимо сам, отработав код (clPersistent, clClient)::Read() и, если нужно, (clPersistent, clVendor)::Read()
И не надо дополнительно городить класс clPersistentClientAndVendor, который объединит в себе всю весёлую компанию и в методе clPersistentClientAndVendor::Read() сам вызовет clPersistentClient::Read() и clPersistentVendor::Read().
S>А просто отобразить поля объекта в поля таблиц базы данных — как два пальца об асфальт.
Люди головы ломают, научные труды пишут, ООБД выдумывают, а Вы — "об асфальт". Не хорошо. Поищите в сети MappingObjects.pdf. Там эта проблема рассмотрена подробно. Описано три подхода. Честно скажу, ни один из них мне не кажется идеальным.
V>>Поправлю: один класс — одна табличка. В статье я специально оговорился про подчинённые таблички. S>Э, нет. Вы в самом начале отказались от того, чтобы объекты имели класс. Они у вас принадлежат произвольному множеству классов, причем это индивидуально контролируется на уровне каждого объекта. Помните? Вот у нас есть три реальных класса X, Y, Z. Еще четыре штуки виртуальных. И объекты, принадлежащие всем восьми комбинациям (включая пустую) зараз. Ну и по каким табличкам мы все это раскладываем? А, ну да. Вот теперь мы получили проблему.
В фразе "один класс — одна табличка" не имелись в виду чисто виртуальные классы. Виртуальный класс, конечно, может захотеть дописать что-то в отдельную табличку, но только в том случае, если это в нём прямо прописать. Тогда по-любому пришлось бы городить отдельную табличку, даже если программа пишется на Бейсике.
V>>1. Отказ от наследования — это не отличие? S>У вас нет никакого отказа от наследования. Оно торчит из статьи, как кроличьи уши из шляпы. Или вы называете принудительное добавление классов-предков к классу объекта отказом от наследования? Да тут больше наследования, чем в классике! Раньше наш XYZ спокойно наследовался от XY, и горя себе не знал. A тут ему говорят, что его дядя XZ и тетя YZ теперь тоже его родители, и жить будем все вместе. И объясняют это отказом от наследования.
См. выше.
V>>2. Проблема неопределённости последовательности вызовов решаема. Например так, как я написал выше. Или даже как-нибудь более элегантно. S>В вашем объяснении выше не сказано, в каком порядке будут вызываться методы. А рассуждения в статье насчет параллельного выполнения — вообще ужасны. В каком состоянии находится ваш объект в процессе выполнения метода? Как вы собираетесь гарантировать его целостность в этом случае?
Уговорили, напишу. Двумя словами отделаться не получится.
Re[5]: Статья про развитие идей ООП. Жду комментариев.
Здравствуйте, Voblin, Вы писали:
V>Конечно, каждое сочетание классов "наследует" свойства и методы всех своих подмножеств. Т.е. XY наследует всё и от Х, и от Y. Только вор в системе нет такого класса — XY. Есть объекты, принадлежащие и X, и Y (и, возможно, куче всего другого дополнительно), но класса такого нет. Итак, кто у кого что наследует? Класс XY у классов X и Y? Нет такого класса — XY! Есть объекты A(X), B(Y), C(XY), D(XYZ), которые получают свойства, методы и реализации методов классов X, Y и XY. Но это же не наследование, когда от класса к экземпляру! Наследование — это когда от класса к классу! Семантически в результате может получиться похоже, но... может и не получиться.
Вот-вот, давайте-ка про семантику поговорим. Я не вижу смысла отделять "от класса к классу" от "от класса к экземпляру". В вашей системе всегда можно ввести безымянный класс, который и будет наследовать все что нужно от всего что нужно. Ну вот например для того самого объекта классов X, Y, и Z одновременно — ведь все объекты, которые указали при своем конструировании эти три класса, ведут себя одинаково! Они наследуют ровно один и тот же набор методов. Вы сами сказали при обсухдении айбо, что класс двух объекта, задекларировавших одинаковые списки классов, совпадает. Ну вот он и есть тот самый безымянный класс, которого вы так избегаете! Он есть де-факто, хоть имя его В Раздоле Не Произносят.
Могу подсказать: для того, чтобы с сточки зрения семантики можно было говорить о прямом наследовании от класса к экземпляру, потребуется что-то типа возможности переопределять методы на уровне экземпляров. Хотя наследование (в каком-то смысле) все еще останется. Но по этому пути я идти не рекомендую — посмотрите на JavaScript. Прекрасный язык, но в нем нет типизации.
Если я ошибаюсь, то объясните поподробнее, в каком же именно случае семантика прямого указания всех классов будет отличаться от введения безымянного промежуточного класса?
V>Здесь интересно то, что метод clPersistent::Read() загрузит из БД всё что необходимо сам, отработав код (clPersistent, clClient)::Read() и, если нужно, (clPersistent, clVendor)::Read() V>И не надо дополнительно городить класс clPersistentClientAndVendor, который объединит в себе всю весёлую компанию и в методе clPersistentClientAndVendor::Read() сам вызовет clPersistentClient::Read() и clPersistentVendor::Read().
Ага! Вот теперь мы начинаем постепенно уползать от классики, так как экземпляр начал мутировать в процессе жизнедеятельности. Да, в классике почти везде класс объекта неизменен в течение всего времени жизни, и сама возможность динамически его изменить — сильная штука. Но почему вы ни слова не пишете об этом в статье? Это очень интересная тематика, тут подстерегает очень большое количество проблем. С большим интересом прочитаю побольше о том, как вы себе представляете семантику такой мутации объекта, который начал жизнь поставщиком, а попутно стал производителем.
S>>А просто отобразить поля объекта в поля таблиц базы данных — как два пальца об асфальт. V>Люди головы ломают, научные труды пишут, ООБД выдумывают, а Вы — "об асфальт". Не хорошо. Поищите в сети MappingObjects.pdf. Там эта проблема рассмотрена подробно. Описано три подхода. Честно скажу, ни один из них мне не кажется идеальным.
Читал я это. Ну и что? Да, все три неидеальны. Но поймите, что проблемы в этом нет. Все уже обсосано до упора. И ООБД с этими возможностями на рынке уже лет десять пасутся. Проблема в том, что реляционная алгебра работает с данными, а ООП — с поведением. Несмотря на ортогональность этих концепций, пока не получается получить приемлемую производительность при их совместном использовании.
Хорошо, опишите тогда подробнее, чем ваш подход будет так уж лучше предлагаемых Амблером.
V>В фразе "один класс — одна табличка" не имелись в виду чисто виртуальные классы. Виртуальный класс, конечно, может захотеть дописать что-то в отдельную табличку, но только в том случае, если это в нём прямо прописать. Тогда по-любому пришлось бы городить отдельную табличку, даже если программа пишется на Бейсике.
Я вам еще раз намекаю, что ваша система как раз очень плохо отображается в RDBMS. В отличие от, например, жестко типизированной системы с одиночным наследованием Object Pascal.
V>Уговорили, напишу. Двумя словами отделаться не получится.
Давайте, пишите. Я бы на вашем месте сосредоточился на отличиях предлагаемой вами системы от существующих моделей. Одинаковости превозносить смысла нет — они уже прекрасно аргументированы в трудах Великих.
... << RSDN@Home 1.0 beta 6a >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Статья про развитие идей ООП. Жду комментариев.
Здравствуйте, Sinclair, Вы писали:
S>Могу подсказать: для того, чтобы с сточки зрения семантики можно было говорить о прямом наследовании от класса к экземпляру, потребуется что-то типа возможности переопределять методы на уровне экземпляров. Лучше смерть.
S>Если я ошибаюсь, то объясните поподробнее, в каком же именно случае семантика прямого указания всех классов будет отличаться от введения безымянного промежуточного класса?
Такой пример:
class X {...};
class Y {...};
class Z {...};
class XY: X, Y {...};
class XZ: X, Z {...};
class YZ: X, Z {...};
class XYZ: ?????? {...};
// Может быть, так?class XYZ: X, Y, Z {...}; // вариант 1 - очевидная глупость
// Или так?class XYZ: XY, XZ, YZ {...}; // вариант 2 - самое логичное
// Или вот так? class XYZ: XY, XZ {...}; // вариант 3 - склероз замучил
Семантически эквивалентным моей схеме будет вариант 2, т.к. только в этом случае все переопределённые методы в принципе доступны. И то, если программист не забудет повызывать родительские методы.
S>Ага! Вот теперь мы начинаем постепенно уползать от классики, так как экземпляр начал мутировать в процессе жизнедеятельности. <...>
Тема мутации объектов безусловно требует дальнейшего раскрытия, тем более, что в предложенную мной схему она настойчиво напрашивается. ОК, поставим ещё одну галочку.
S>Хорошо, опишите тогда подробнее, чем ваш подход будет так уж лучше предлагаемых Амблером.
Отдельная тема для пространных наукообразных рассуждений. Будет время — залезу в неё.
V>>В фразе "один класс — одна табличка" не имелись в виду чисто виртуальные классы. Виртуальный класс, конечно, может захотеть дописать что-то в отдельную табличку, но только в том случае, если это в нём прямо прописать. Тогда по-любому пришлось бы городить отдельную табличку, даже если программа пишется на Бейсике. S>Я вам еще раз намекаю, что ваша система как раз очень плохо отображается в RDBMS. В отличие от, например, жестко типизированной системы с одиночным наследованием Object Pascal.
V>>Уговорили, напишу. Двумя словами отделаться не получится.
S>Давайте, пишите. Я бы на вашем месте сосредоточился на отличиях предлагаемой вами системы от существующих моделей. Одинаковости превозносить смысла нет — они уже прекрасно аргументированы в трудах Великих.
Итак, в статью нужно добавить следующее:
1. Сравнение с mixin-технологией (вполне логичное пожелание Akzhan)
2. Способы придания предсказуемости вызовам методов объектов.
3. Мутация объектов.
4. Те изменения, которые вносит предлагаемая технология в процесс проектирования систем. Здесь и кроятся основные отличия от трудов Великих.
Re[7]: Статья про развитие идей ООП. Жду комментариев.
Здравствуйте, Voblin, Вы писали:
S>>Если я ошибаюсь, то объясните поподробнее, в каком же именно случае семантика прямого указания всех классов будет отличаться от введения безымянного промежуточного класса? V>Такой пример: V>
V>class X {...};
V>class Y {...};
V>class Z {...};
V>class XY: X, Y {...};
V>class XZ: X, Z {...};
V>class YZ: X, Z {...};
V>class XYZ: ?????? {...};
V>// Может быть, так?
V>class XYZ: X, Y, Z {...}; // вариант 1 - очевидная глупость
V>// Или так?
V>class XYZ: XY, XZ, YZ {...}; // вариант 2 - самое логичное
V>// Или вот так?
V>class XYZ: XY, XZ {...}; // вариант 3 - склероз замучил
V>
V>Семантически эквивалентным моей схеме будет вариант 2, т.к. только в этом случае все переопределённые методы в принципе доступны. И то, если программист не забудет повызывать родительские методы.
Но ведь это никак не противоречит наличию такого класса! Класc XYZ есть, как бы он ни был продекларирован! Я согласен, что наиболее полным аналогом наследования, принятого в вашей модели является автоматическое зачисление в предки класса всех "вычетов", т.е. классов, которые были так же унаследованы от всех подмножеств множества исходных предков, которые которых... Тьфу, пропасть!
Короче, как только мы пишем
[virtual language]
class XYZ: X, Y, Z {}
[/virtual language]
Мы подразумеваем
class XYZ: virtual XY, virtual XZ, virtual YZ {...}; // вариант 2 - самое логичное
А когда мы пишем
[virtual language]
class XYZW: X, Y, Z, W {}
[/virtual language]
То есть для четырех классов будем брать все тройки, для трех — двойки. Очевидно, что при таком рекурсивном определении класс XYZW унаследует все поведение (т.е. методы) и от классов X, Y, Z, W, XY, XZ, XW, YZ, YW, ZW.
Вот это уже похоже на отличие схемы наследования (я бы не рискнул называть это отсутствием наследования) от классических языков. Надо только понять, наскольо такая надстройка над объектностью оправдана — также, как С++ в свое время взял часть рутинной работы С-программиста на себя, эта система типизации тоже берет часть работы на себя. Но при этом ценой является некоторое уменьшение гибкости.
V>Тема мутации объектов безусловно требует дальнейшего раскрытия, тем более, что в предложенную мной схему она настойчиво напрашивается. ОК, поставим ещё одну галочку. V>Отдельная тема для пространных наукообразных рассуждений. Будет время — залезу в неё.
V>>>В фразе "один класс — одна табличка" не имелись в виду чисто виртуальные классы. Виртуальный класс, конечно, может захотеть дописать V>>>Уговорили, напишу. Двумя словами отделаться не получится.
V>Итак, в статью нужно добавить следующее: V>1. Сравнение с mixin-технологией (вполне логичное пожелание Akzhan) V>2. Способы придания предсказуемости вызовам методов объектов. V>3. Мутация объектов. V>4. Те изменения, которые вносит предлагаемая технология в процесс проектирования систем. Здесь и кроятся основные отличия от трудов Великих.
Нет предела совершенству! Буду с интересом ждать выхода следующей версии
И перейдем к вопросам производительности
... << RSDN@Home 1.0 beta 6a >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Статья про развитие идей ООП. Жду комментариев.
Здравствуйте, Sinclair, Вы писали:
S>И перейдем к вопросам производительности
Насчёт производительности — это не ко мне. Это к фирме Intel. Позвать Гордона Мура.
Конечно, производительность будет напрямую зависеть от того, насколько эффективным получится сделать механизм построения списка подходящих реализаций виртуальных методов. Здесь можно вовсю побаловаться конечными автоматами, кэшированием в VMTable,...
Не буду об этом думать сегодня. Подумаю об этом завтра.
(с) С.О`Хара
Что уж говорить, сейчас подавляющее большинство (если скажу 90%, сильно не ошибусь) систем автоматизации основано на средстве разработки, дающем порядка 2 млн. элементарных операций в секунду на процессоре 2Ггц. Т.е. эффективность порядка 0.1% И что? Да ничего! Все довольны!
Часто борятся две тенденции:
Интеллектуальность среды => эффективные алгоритмы => повышение быстродействия
Интеллектуальность среды => тормоза в движке => понижение быстродействия
Пока счёт равный. Привести примеры можно как в ту, так и в другую сторону.
Re[9]: Статья про развитие идей ООП. Жду комментариев.
Здравствуйте, Voblin, Вы писали:
V>Насчёт производительности — это не ко мне. Это к фирме Intel. Позвать Гордона Мура.
Офф:
Есть такое слово — масштабируемость. Это означает, что линейные алгоритмы — это верхний предел допустимой неоптимальности. Ну, в худшем случае О(N*logN). Все, что медленнее — сосет. RDBMS рулят из-за линейного объема и логарифмического поиска. Точка. Дело не в том, что ODBMS делают что-то в 10^K раз медленнее, дело в том, что в мало-мальски интересных случаях они сразу заменяют O(logN) на O(N).
... << RSDN@Home 1.0 beta 6a >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Статья про развитие идей ООП. Жду комментариев.
а автор на мой взляд не предлагает ничего, четко сформулированного,
с другой строны ООП весьма обсужденная вещь, чтобы предполагать что в ней
такие явные недостатки, (как шаблоны).
Давайте Обсудим и мы. Это полезно.
Погрешности:
" При реализации полиморфизма через виртуальные классы программа, написанная забывчивым разработчиком, не будет аварийно завершаться с сообщением об ошибке. Она просто не будет выполнять требуемое действие. Как к этому относиться – не знаю."
Все знают — что плохо. Это вопрос стиля и его соответствия свободе программирования.Выбор за программером.
"Не знаю как кто, но я бы об избавлении от шаблонов не жалел ни секунды."
Классическое "Современное пректирование" в некоторых основных частях основано именно на шаблонах,
как эффективной вещи.
В частности миксинахи высокоструктурных компонентах.
С другой стороны вы не предложили достойной альтернативы.
"Реализация таких методов весьма накладна. Определение перечня задействованных реализаций в любом случае намного дольше отработки процессорной инструкции CALL.
Они никогда не смогут быть in-line. "
— не интересует мелкая накладность- интересует правильная оргпнизация проекта, чтобы он не провалился.
Вы начали обсуждатьно не предложили конкретно как сделать большой проект с большой вероятностью не провальным.
"множественной классификации." — вещь хорошая — это то же множественнео наследование,
или миксины или в чем явное отличие,
и какие выгоды от всего этого?
"Обман компилятора" — нехорошая вещь —
компилятрор ваш друг в поиске ошибок,
которые угробили бы ваш проект в дестяки раз быстрее.
"Будем считать вопрос строгой типизации закрытым. "
Надо писать "предлагаю" — но вы не написали серьещно почему?
Нет критериев.
Плохая проработка.
В общем это больше описание известных методов в
предложении представитьв новом языке.
Или не показано явное отличие.
Узнать о них можно -поэтому печатать полезно.
Но не супер.
Здравствуйте, Voblin, Вы писали:
V>Прочитать можно там же.
Чем дольше думаю, тем явственнее мысль — не туда забрели.
В своей статье Вы полагаете объект некоей кучей иных объектов
Хотя все Ваши цитаты из реального мира прямо говорят о дргом подходе:
Объекты в природе сами по себе целостны (как Вы говорите, элементарны).
А множество определений для одного и тог же объекта можно строго определить различными точками зрения на один и тот объект (в принципе отсюда в оригинале и пляшет концепция контрактов-интерфейсов).
Вдумайтесь: та же кошка не является кучей точек зрения, вместе собирающихся в нечто единое (подход слепцов и слона). Наоборот — кошка — это строго и заранее определённый (с точностью до реализации) объект, который наше восприятие способно воспринимать с различных точек зрения.
Отсюда вывод: небоходимость динамической генерации комплексных типов взята с потолка. Когка должа быть определена на этапе разработки библиотеки "животный мир/кошачьи".
Можно для нашего класса
WorldObject
создать некие методы
bool queryViewPoint(ViewPointId viewPointId, out ViewPointContract viewPointContract);
Здравствуйте, Voblin, Вы писали:
V>Прочитать можно там же.
Сдается мне, вас понесло не в ту сторону.
В работе никак не отражены важнейшие результаты, полученные за последние двадцать пять лет.
И упор делает все на тот же статический ООП, который сводит объектный подход фактически на нет.
Об этом постоянно предупреждал Алан Кей.
Он указывал на то, что ООП свели к второстепенным деталям — inheritance и reuse. В то время, когда вся идея целиком построена вокруг messaging. И важнейшим выигрышем является не reuse, как принято считать, а immediacy — опыт непосредственного взаимодействия с объектной системой, что позволяет певратить компьютер в такой же инструмент (для работы или творчества) как карандаш, книгу и т.д.
Эта проблема четко указывается даже в такой критической статье как Objects Have Failed (by Richard Gabriel)
===
Objects, as envisioned by the designers of languages like Smalltalk and Actors—long before C++ and Java came around— were for modeling and building complex, dynamic worlds. Programming environments for languages like Smalltalk were written in those languages and were extensible by developers. Because the philosophy of dynamic change was part of the post-Simula OO worldview, languages and environments of that era were highly dynamic.
But with C++ and Java, the dynamic thinking fostered by object-oriented languages was nearly fatally assaulted by the theology of static thinking inherited from our mathematical heritage and the assumptions built into our views of computing by Charles Babbage whose factory-building worldview was dominated by omniscience and omnipotence.
And as a result we find that object-oriented languages have succumb to static thinkers who worship perfect planning over runtime adaptability, early decisions over late ones, and the wisdom of compilers over the cleverness of failure detection and repair.
===
В последнее годы Алан Кей прочитал ряд интересных лекций:
The Computer Revolution Hasn't Happened Yet
Daddy, Are We There Yet?
Croquet: A Collaboration Architecture
В них стречается ряд интересных высказываний:
* Последние 30 лет были скучными в IT, не сделано никаких сколь-нибудь значительных открытий
* То, что Croquet реализован на Squeak (фактически Smalltalk-80 — технология 75-ого), фактически является показателем ужасного состояния IT индустрии. Получается, с тем пор не было предложено ничего лучшего в рамках объектного подхода.
* Lisp фактически явился главных фундаментом при создании объектного подхода. Это некий математический объект, способный описать самого себя. Оттуда были взяты идеи динамической среды и наличие максимально простой масштабируемой концепции.
* Java не внесла абсолютно ничего нового в науку (изначально являясь языком, разработанным для тостеров). И она преподается в университетах под маркой Computer Science. Ее преподавание сгодилось бы в рамках курсов выходного дня, но никак не CS.
Также Алан Кей считает, что за последние десятилетия наиболее важной работой в этой сфере является PIE — Layered Approach (by Ira Goldstein and Daniel Bobrow).
Туда же можно приплюсовать работу создателей языка Self — A Simple and Unifying Approach to Subjective Objects (by Randall Smith and David Ungar).
В этих работах рассматривается вопрос представления объектной системы по-разному с разных точек зрения. Фактически субъектно-ориентированный подход. По-видимому, это следующий логический шаг в развитии ОО.
--
Владимир.
Re[2]: Статья про развитие идей ООП. Жду комментариев.
Здравствуйте, vgrigor, Вы писали:
V>Я вот буду не соглашаться с автором,
V>по следующим аспектам: V>я пишу как правило реальную программу, V>и с базрой данных, иногда с интеренет, со слоями,
Тоже дело, тоже балуюсь, но шило в заднице мешает сидеть спокойно
V>И я не увидел ни одной полезной строки для этого.
Я пока тоже. Ждём развития событий.
[мыши погрызли]
V> а автор на мой взляд не предлагает ничего, четко сформулированного, V>с другой строны ООП весьма обсужденная вещь, чтобы предполагать что в ней V>такие явные недостатки, (как шаблоны).
Некоторые никогда не устанут обсуждать погоду, некоторые — правительство, а некоторые — ООП.
V>Погрешности: V>" При реализации полиморфизма через виртуальные классы программа, написанная забывчивым разработчиком, не будет аварийно завершаться с сообщением об ошибке. Она просто не будет выполнять требуемое действие. Как к этому относиться – не знаю." V>Все знают — что плохо. Это вопрос стиля и его соответствия свободе программирования.Выбор за программером.
Суть ошибки забывчивого программера в том, что он не дописал ту функциональность, которая должна быть в программе.
Среда разработки (или выполнения) на это может среагировать двумя способами:
1. При первом удобном случае размазать несчастного по стенке. Программисты этого не любят, и поэтому, как правило, пишут быстренько затычки для виртуальных методов, чем сводят поведение системы ко второму способу.
2. Просто не делать то, что не запрограммировано. Запрограммирует — будем делать, не запрограммирует — адью.
Не вижу ничего плохого в том, чтобы система всегда шла по второму пути, но, как всегда, готов выслушать аргументированные возражения.
V>"Не знаю как кто, но я бы об избавлении от шаблонов не жалел ни секунды." V>Классическое "Современное пректирование" в некоторых основных частях основано именно на шаблонах, V>как эффективной вещи. V>В частности миксинахи высокоструктурных компонентах. V>С другой стороны вы не предложили достойной альтернативы.
Пардон, а для чего альтернатива? Для того, чтобы продолжать заниматься теми страшными извращениями, которые обычно реализуются на шаблонах? Господа! Подавляющее количество языков программирования не имеет механизма шаблонов, и не потому, что разработчики компилятора — недоумки, а потому, что это в них не нужно.
V>"Реализация таких методов весьма накладна. Определение перечня задействованных реализаций в любом случае намного дольше отработки процессорной инструкции CALL. V>Они никогда не смогут быть in-line. " V>- не интересует мелкая накладность- интересует правильная оргпнизация проекта, чтобы он не провалился.
Мне показалось полезным обсудить такую фичу, хотя соглашусь, что обсуждаемый раздельчик выглядит слегка инородным.
V>Вы начали обсуждатьно не предложили конкретно как сделать большой проект с большой вероятностью не провальным.
Как сделать проект с большой вероятностью не провальным, я не скажу. И не просите. Речь шла о том, как сделать проект с большей вероятностью не провальным. Разница — буква.
Как же сделать проект с большей вероятностью не провальным? Я предложил сильно упростить этап классификации и дополнительно к этому смягчить последствия ошибок, допущенных на нём.
V>"множественной классификации." — вещь хорошая — это то же множественнео наследование, V>или миксины или в чем явное отличие, V>и какие выгоды от всего этого?
Отличие — в том, что предложено делать типы объектов неатомарными.
При ЛЮБОМ навороте в ЛЮБОМ существующем языке программирования тип объекта ВСЕГДА атомарен. Что бы мы ни взяли, множественное наследование, миксины, составные типы или даже Variant, мы всегда имеем дело с атомарным типом.
В раздельчике "Классификация/Что же предлагается" про это подробно написано (только слово "атомарность" не упоминается чтобы людей не дразнить наукообразием).
V>"Обман компилятора" — нехорошая вещь - V>компилятрор ваш друг в поиске ошибок, V>которые угробили бы ваш проект в дестяки раз быстрее.
Хорошо это или не хорошо, но соблазн у программера есть всегда.
Конечно хотелось бы сделать так, чтобы корректность мутаций чётко и надёжно контролировалась компилятором, но сделать это ой как не просто!
V>"Будем считать вопрос строгой типизации закрытым. " V>Надо писать "предлагаю" — но вы не написали серьещно почему? V>Нет критериев. V>Плохая проработка.
Да ну? По-моему, вполне доходчиво это было доказано.
Если эта фраза была воспринята в том смысле, что все среды программирования, не имеющие строгой типизации must die, то извините. Конечно, утверждение справедливо только в контексте множественной классификации.
V>В общем это больше описание известных методов в V>предложении представить в новом языке. V>Или не показано явное отличие.
Во люди дают! Им весь процесс построения системы классов перевернули вверх тормашками, попутно показав, насколько это хорошо сочетается с РБД, легитимизировали мутацию и избавились от шаблонов, а оказалось всё мало.
Думаю, старый ассемблерщик, почитав про ООП, мог бы сказать что-то вроде такого: "Да это и так всё давно известно и используется! Посмотрите хотя бы мой [censored].asm!"
на чём основано. Когда это пытаешься склеивать, возникают противоречия.
Лучше смерть.
