Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, borisman2, Вы писали:
B>>Кстати, Вы заметили, что наш с Вами подход к ОО моделированию сильно пошел в разрез с реализацией ООП как такового ? WH>Какого ООП? Они бывают разные... Есть WH>1)Наследование WH>2)Инкапсуляция WH>3)Полиформизм WH>А есть ООП по Алану Кейю(на счет имени не уверен ) WH>1)Объект — базовая единица системы. WH>2)Объекты обладают состоянием. WH>3)Единственным способом взаимодействия между объектами является посылка сообщения. Объекты сами определяют как обрабатывать сообщения.
Прошу прощения за очень краткую и непонятную фразу, я, конечно, имел в виду первое общепринятое определение ООП. После двух лет программирования на динамическом языке трудно не согласиться с Аланом Кеем в том, что такое определение несколько не соответвует базовым идеям, разработанным автором Smalltalk. Но это оффтопик, отдельная тема, если есть желание можно обсудить, конечно. Хотя вроде бы уже было такое обсуждение.
Большое спасибо за отклик, действительно, приведенные паттерны помогают выйти из положения. Но, я так понял, большинство из них обладают одним недостатком: нужно заранее знать, какие у пользователя будут роли. Это не всегда удается.
B>только, справедливости ради, я хотел бы сказать, что у StanislavK это получилось более просто, понятно и абстрактно.
В общем, да. Сразу не углядел я тот ответ StanislavK.
У меня оно более подробно раскрыто. Ну, ещё важное отличие в том, что он называет свои классы дополнительной функционельности свойствами, а я свои — ролями. Согласитесь, так гораздо осмысленнее...
, в которых наши Person-ы могут выступать.
(хотя "this is not Python way" (c) Гвидо ван Россум ).
B>Абсолютно верно! Однако, ведь весь огород городится вовсе не из-за того, чтобы получить доступ к каким-то там новым атрибутам. Весь огород городился ради того, чтобы можно было объект рассматривать как объект ДЕЙСТВИТЕЛЬНО нового класса.
А зачем?
E>>Но оно и не нужно, если вдуматься. Вот такое решение выглядит ничуть не сложнее: E>>
B>Тоже верно! Но только зачем создавать дополнительные сущности без необходимости?
Действительно, зачем?
Для чего использовать решение, приводящее к смене на рантайме класса объекта?
Ведь на самом-то деле, в процессе всех прептурбаций, основный их тип не меняется — они как были, так и остаются Person-ами. Это их свойство неизменно, значит именно его и следует выбрать в качестве класса. А все остальное (User, Applicant, Married) это всего лишь роли (нечно наносное, меняющееся динамически), в которых наши люди могут выступать.
Здравствуйте, borisman2, Вы писали:
B>Здравствуйте, StanislavK, Вы писали:
B>>> — <<Почему так происходит>> B>>>Проблема в том, что статическое описание классов (диаграмма классов) не может описать динамический характер предметной области.
B>Кстати, Вы заметили, что наш с Вами подход к ОО моделированию сильно пошел в разрез с реализацией ООП как такового ? Это наша с Вами проблема или проблема ООП ? Я давно подозреваю, что ООП вообще вещь очень мутная — черти там водятся...
Здравствуйте, StanislavK, Вы писали:
SK>Не не заметил. Поясни.
Ок, на самом деле это немног оне в тему. Однако, решить проблему динамической классификации обычными средствами классификации (иерархии классов) оказалось невозможно (оно и ясно...) и пришлось частично самим реализовывать классификацию объектов (посредством вектора свойств). Впрочем, это спорный вопрос, связанный с определением самого ООП.
, в которых наши Person-ы могут выступать. E>(хотя "this is not Python way" (c) Гвидо ван Россум ).
Решается, верно. Неудобно, но можно. А Питонный путь ничем не лучше других, таких как Delphi way, C++ way, My way, AmWay . К счастью, религиозный период а программировании я уже прошел. Особых разногласий с Вами не имею.
E>Для чего использовать решение, приводящее к смене на рантайме класса объекта? E>Ведь на самом-то деле, в процессе всех прептурбаций, основный их тип не меняется — они как были, так и остаются Person-ами. Это их свойство неизменно, значит именно его и следует выбрать в качестве класса. А все остальное (User, Applicant, Married) это всего лишь роли (нечно наносное, меняющееся динамически), в которых наши люди могут выступать.
Да, но вроде как ОО моделирование именно и строится на том, чтобы объекты реального мира классифицировать, потому может быть их надо именно КЛАССИФИЦИРОВАТЬ, путь даже динамически ?
Здравствуйте, eugals, Вы писали:
E>Я бы сделал как-то так:
Круто. Собственно, все построено на том, что классификация делается динамически. Т.е. поддержка ролей является свойством не класса, а конкретного объекта. Выглядит все, конечно, красиво. Более того, существуют среды типа того же самого Delphi где приведение типа автоматически делается на уровне объекта, а не класса. (По-моему, в этом топике на это внимание уже обращали).
Смущает меня только один вопрос. Вот взяли мы и сохранили где-то ссылку на полученный таким образом IMarried. Как выполнить развод? Фишка в том, что добавление ролей никак не нарушает типизации. В системах со сборкой мусора персона просто не сможет получить развод, пока хоть кто-то знает о том, что она была жената.
Хотя это, скорее, общефилософский вопрос к системам с динамической классификацией: как быть в случае отказа от исполнения роли?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Хотя это, скорее, общефилософский вопрос к системам с динамической классификацией: как быть в случае отказа от исполнения роли?
Да, сложный вопрос.
Собственно, в данном конкретном случае эту проблему можно решить введением временных границ связи.
То есть расширить интерфейс IMarried так:
Видимо подобное решение (отслеживание актуальности и/или истории ролей) подходит и для общего случая.
Понятно, что при этом код использующий такие интерфейсы сильно усложняется соответствующими проверками
Наверное существуют какие-то способы борьбы с этой проблемой. Те же самые исключения, например. Или (это у меня уже поток сознания пошел... ) какое-нибудь деление цикла обработки на интервалы актуальности, этакие глобальные state-ы (похожие на транзакции) программы, в которых гарантирована валидность полученных интерфейсов...
тема интересная, будем думать...
Здравствуйте, borisman2, Вы писали:
A>>Смотрю я на это, и вижу сплошные интерфейсы. Т.е. класс, выдающий (реализующий) несколько интерфейсов по запросу. Надо юзера — запросил интерфейс юзера, ещё кого — тоже просим. Проверить, поддерживает ли нужный нам интерфейс — тоже можем.
B>Вкратце. Интерфейсы тут вообще не при чем.
насчет интерфейсов имелось виду (как я понимаю) следующее: .
(пример на Делфях)
type
IAbsract = interface
procedure AddSupport(intf: IUnknown);
procedure RemoveSupport(intf: IUnknown);
function Support(IID: TGUID): Boolean;
end;
IPerson = interface(I)
property Name: string;
end;
IUser = interface
property Login: string;
end;
...
obj.AddSupport(CreateUser(...));
obj.AddSupport(CreatePerson(...))
//переписываем QueryInterface и имеем удобную запись
(obj as IPerson).Login
Здравствуйте, borisman2, Вы писали:
A>>Смотрю я на это, и вижу сплошные интерфейсы. Т.е. класс, выдающий (реализующий) несколько интерфейсов по запросу. Надо юзера — запросил интерфейс юзера, ещё кого — тоже просим. Проверить, поддерживает ли нужный нам интерфейс — тоже можем.
B>Вкратце. Интерфейсы тут вообще не при чем.
Ну почему... Я попробую пояснить...
ООП, основанную на 3 принципах (И., Н., П.) мы знаем. Это хороший, функциональный инструмент замоделировать практически любую предметную область. Но как обычно, палка бывает о двух концах. (Хотя, я думаю, что о трёх. )
Мне видится такой недостаток. Пусть существует некая идеальная модель предметной области. На построение такой модели я должен затратить А единиц времени полюс другие ресурсы. В случае отсутствия у меня опыта моделирования предметной области вообще или именно такой конкретной области мне будет также нехватать опыта, а время будет стремительно утекать. Нельзя сказать, что бесцельно, но неэффективно.
Но не моя неопытность в моделировании будет недостатком. Предметная область находится в движении, подвержена изменениям. Сделав снапшот предметной области сейчас мы рискуем завтра нарваться на "необратимые" и "неучтённые" изменения. Именно поэтому есть проблемы при проектировании к.-л. продукта, проблемы с доработками от заказчика продукта.
Вот и возникают подобные ситуации, когда вначале был человек, потом понадобилось сделать его пользователем, потом подателем заявлений, потом снежный ком. Само собой, идеальная модель есть. Она есть всегда, это лишь вопрос времени. Но идеальная модель жёстка, она напоминает застывшую воду — лёд, который хорошо и прочно смотрится с моста, но стоит ступить на него, и можно провалиться в водоём. Хорошо, если просто потрескается, можно накатить воды и подморозить...
Вот эта изменчивость моделируемого мира и доставляет неприятности. Ведь так хочется всё предусмотреть, чтобы было красиво. А ведь эта цель недостижима для реалтайма.
Но так ли всё печально? Неужто нельзя заставить модель меняться в зависимости от изменения мира? И каковы будут затраты на такое чудо? А может не надо такого?
Идея интерфейсов мне кажется здесь весьма замечательной. Помните, да, что однажды объявленный интерфейс изменению не подлежит. Это снапшот предметной области. Не важно, просто по имени его идентифицировать, или с COM-наворотами с guid.
Но интерфейсы позволяют мне реагировать на изменения предметной области, само собой с некоторой долей инерционности, но зато менее болезненно. Старые модели будут запрашивать "старые" интерфейсы, новые будут пользоваться преимуществом самого свежего варианта. При всём при этом сохраняется концепция "чёрного ящика": класс выдаёт реализуемые интерфейсы, а как он это делает, для потребителя интерфейсов дело десятое. Хочешь ешь, не хочешь — не ешь.
B>Задача была в том, чтобы пользователь мог определить, к какому КЛАССУ относится данный объект, и, при необходимости, классифицировать его по-новому, т.е. отнести его к новому классу предметов.
Звучит немного оригинально и непривычно. "Вчера ты был шкафчик, теперь ты тумбочка. И все вы, этого типа, тоже теперь тумбочки, поняли! И где ваши зеркальца? Полочки выкинуть, зеркальца вправить..."
Вариант с интерфейсами выглядит более привычно. "- Шкафчик дай? — Пжалуста. — Тумбочку, ещё, ещё 10 штук. — Пжалуста. — Зеркальце есть? — Не понимаю, о чём вы говорите. — Ну и фиг с ним, полками обойдёмся..."
B>Да, в общем-то Вы верно оцениваете ситуацию. Тот же самый объект. Тот же самый юзер. Только, сегодня выяснилось, что он не только юзер, но еще и программер. В этом вся прелесть...
Я полагаю, что данную задачу можно решить несколькими способами. Каждый будет иметь как преимущества, так и недостатки. Баланс штука тонкая.
Можно написать несколько классов, создавать их, заставлять пользователя модели проверять их тип. Можно определить несколько интерфейсов, заставить их запрашивать. А можно... Нет, не буду.
B>Насчет коллекций, мне кажется, или Вы немного недопоняли меня
Возможно. Я имел ввиду списки экземпляров объектов, объединённых некоторой логикой модели предметной области, причём объект может принадлежать нескольким спискам, в зависимости от требуемой логики модели.
И не важно, будет это набор таблиц в БД, TList в Дельфи или просто array of Нечто, суть от реализации не меняется.
... << RSDN@Home 1.1.4 beta 3 rev. 189 Тишь да гладь, да Божья благодать >>
Здравствуйте, borisman2, Вы писали:
B> — <<Приветсвие>> B>Здравствуйте товарищи программисты!
Угу.
B>Возможно, описанная мной проблема тянет на маленькую статью, поэтому тов. модераторы, можете перенести ее туда, куда Вам покажется более верным.
B>Строго говоря, этот пост не является каким-то конкретным вопросом. Просто я излагаю свою небольшую идею и хочу знать, как эту идею примет уважаемое сообщество RSDN. Единственная просьба — не бейте камнями, а точнее вопросами — "Да зачем все это надо ??? У меня вот нет таких проблем... потому что я пишу вот так мол и так...", поймите, я не могу отмахнуться от задачи, просто отказавшись ее решать. B> — <<Введение>> B>Меня зовут Борис, я работаю в Программе Микрофинансирования Европейского Банка Реконструкции и Развития. Одна из задач, которые передо мной стоят — задача отслеживания заявок, кредитов, заемщиков и т.д. в банках-партнерах, с которыми работает наша Программа. Не вдаваясь а дальнейшие детали, перейду непосредственно к вопросу.
B> + <<Задача: модель данных>>
Стоп! Первые два балла. Задача — модель предметной области. Совет N0 — никогда не моделируйте данные. Моделируйте предметную область.
B>В настоящий момент я разрабатываю модель данных для довольно сложной комплексной проблемы учета. Модель включает в себя массу информации из реального мира, которую не так то просто промоделировать. Конечным результатом должен стать модуль, написанный на языке Python, т.е. грубо говоря, некая иерархия классов, отражающая предметную область.
[...]
B> + <<Основной затык>> B>Разрабатывая проблему, я столкнулся со следующим весьма печальным (и, в общем-то, известным) затыком: статическая объектная модель данных (т.е. иерархия классов) не может достаточно полно и точно описать предметную область.
Может, если не уповать на наследование слишком сильно.
Дальше я поскипал код, а текст постарался сохранить. Сорри за оверквотинг.
B>Сразу оговорюсь, что при разработке модели Я НЕ ПЫТАЛСЯ объять необъятное, т.е. разработать модель для всех возможных случаев. Это попросту невозможно. B> — <<Пример>> B>В предметной области имеются люди как таковые, то есть некоторые объекты, имеющие фамилию имя и отчество (строго говоря, для какой-то другой предметной области важнее будет, что люди имеют, скажем, рост и вес, но в данном случае я разрабатываю совершенно конкретную областьи потому важно именно ФИО),
Да, совершенно согласен — есть сущность агрегативного характера.
B>на C++ это может быть описано примерно так:
B>
B>class Person {...}
B>
B>Люди могут при этом быть пользователями системы: B>
B>class User: public Person {...}
B>
B>Но кроме этого, люди могут быть еще и подателями заявлений
B>
B>class Applicant: public Person {...}
B>
В корне неверно. Люди (Person) могут находиться по отношению к тем или иным подсистемам в тех или иных ролях. Роль — суть независимый объект предметной области.
class Person {...};
class User {
public:
SomeSmartPtr<Person> pPerson_;
};
class Applicant {
public:
SomeSmartPtr<Person> pPerson_;
};
B>Может быть такая ситуация, что человек является подателем заявления (Applicant) но не является пользователем системы (User). B>А может быть и наоборот — человек может являться пользователем системы и не являться подателем заявления.
В том-то и дело! Естественно — может такое быть! Ведь эти роли никак не связаны друг с другом.
B> — <<Почему так происходит>> B>Проблема в том, что статическое описание классов (диаграмма классов) не может описать динамический характер предметной области.
И не надо ей пользоваться для этого. Без наездов, но в данном контексте скорее следует относиться к МН как к технологическому элементу, а не как к средству моделирования отношений в предметной области.
B> — <<Обычное решение>> B>Обычное решение (к сожалению) состоит в том, чтобы отказаться от классического ОО моделирования предметной области, исскуственно упрощая модель данных, например:
B>
B>class User {...}
B>class Appplicant {... duplicate User structure ...}
B>
B>Преимущества и недостатки такого подхода говорят сами за себя: B> \- Это проще реализовать B> \- К сожалению, теперь уже ПРИЛОЖЕНИЕ должно знать о связях между объектами, т.е. приложение должно знать, скажем, что пользователь и заявитель с одинаковыми ФИО — это одно и то же лицо.
Не совсем точная формулировка. Проблема в том, что связи прокладываются неявно и нужен дополнительный "серьёзный" агрегат для их контроля.
B> — <<Возможное статическое решение>> B>Ранее я уже сталкивался с подобной проблемой в более мелких масштабах и решал я ее так:
B>
B>class Person {
B> ...
B>}
B>class User {
B> public Person person;
B>}
B>class Applicant {
B> public Applicant applicant; // Имелось ввиду public Person person? - ГВ
B>}
B>
B>Далее все понятно. Но есть несколько затыков: B> 1) Можно определить, что пользователь является человеком, но не наоборот (нельзя определить что данный конкретный человек является пользователем)
Почему же? Можно. Спросить множество ролей на предмет вхождения туда заданного экземпляра Person.
B> 2) Четкую иерархию классов мы подменили исскуственной иерархией агрегации. Это, в общем, терпимо, однако заставляет нас писать дополнительный проблемно-ориентированный код, который реализует иерархию. Это "грязный хак".
Да прекратите Вы привязываться к "чёткой иерархии классов", которая ничего кроме путаницы не вносит. Давайте утвердимся в мысли, что иерархия — сугубо технологическое понятие. В реальной предметной области как правило можно выделить подобные по структуре элементы и на основании выделенного подобия построить некоторую иерархию. Но и не более того. Ответьте себе на вопрос — а зачем обязательно притягивать за уши иерархию?
B>До сих пор я считал, что это вообще единственное разумное решение.
Дальше я скипнул — объём большой, а идея с микшированием классов — очевидна.
[...]
B>К сожалению, и этот подход ведет в тупик, потому что невозможно изменить класс объекта в рантайме ПРАВИЛЬНО!!! Из этого следует, что не надо называть роль — классом! А если у Вас будет две разновидности Applicant? А если добавится ещё одна система по отношению к которой будет определяться роль User? А если...? Да ещё 33 тысячи таких "если" может быть!
B>т.е. если, например, был у нас Петр Петрович Иванов, и стал он вдруг пользователем системы, это мы уже не сможем выразить в коде. Вот если ЗАРАНЕЕ известно, что Петр Петрович является пользователем системы — тогда все Ок.
Снова Вы совершенно правильно указали проблему. Ну так — остался последний шаг. Измените способ решения.
B> — <<Динамическое решение>> B>К большому моему счастью (и, конечно, к несчастью, потому что в мире вообще сплошные палки с двумя концами) я пишу задачу не на С++, а на Питоне. B>Питон является динамическим языком с очень мощными возможностями интроспекции. В частности, он позволяет изменять класс переменной ВО ВРЕМЯ ИСПОЛНЕНИЯ ПРОГРАММЫ!
Не... ёрничать по части C++ — это моя прерогатива.
B>Идея, кажется, не новая, потому что смутно помню, что я это уже где-то встречал. Но простота, с какой ее можно реализовать на Питоне, меня поразила...
B>Поэтому. Можно писать код в таком виде.
[skip код на Python, ради подавления оверквотинга]
Да. всё верно. Можно изменить класс. Но как насчёт того, чтобы ИЗМЕНИТЬ МНОЖЕСТВЕННОСТЬ отношения экземпляров? Нам известно, что User определён для некоторого одного пользователя, Applicant — тоже. А что насчёт того, что один User может быть юзером в нескольких местах или подателем нескольких разновидностей заявлений? Эдак Вы быстро докатитесь до нескольких классов, по которым будете пулять объекты. Зачем такие сложности?
Да. И на будущее — НЕ ЧИТАЙТЕ НА НОЧЬ АДЕПТОВ ООП! И утром не читайте. И вообще не читайте.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Borisman2, Вы писали:
B>Здравствуйте, Voblin, Вы писали:
V>>Здравствуйте, borisman2,
V>>Я эту тематику проковырял чисто теоретически. V>>См. здесь: http://voblin.nm.ru/objects_classes.dhtml
B>Да, прочитал. Оченб внимательно. Понравилось. Думаю, это можно ПРАКТИЧЕСКИ на Пиотне сделать.
Может быть. Насколько я понимаю, с атрибутами проблем не будет, но пока не понятно, можно ли на Питоне сделать хитрую отработку методов (см. "Реализации интерфейсов при множественной классификации"). А в этом вся соль.
Здравствуйте, Sinclair, Вы писали:
S>Смущает меня только один вопрос. Вот взяли мы и сохранили где-то ссылку на полученный таким образом IMarried. Как выполнить развод? Фишка в том, что добавление ролей никак не нарушает типизации. В системах со сборкой мусора персона просто не сможет получить развод, пока хоть кто-то знает о том, что она была жената. S>Хотя это, скорее, общефилософский вопрос к системам с динамической классификацией: как быть в случае отказа от исполнения роли?
хм... а почему так? почему не переименовать так:
public interface ICanBeMarried: IPerson
{
property bool IsMarried;
}
Что значит "переименовать"? Я не ICanBeMarried. Я уже IMarried. У меня и IPerson IMarried::Spouse есть. Вопрос в том, что делать со ссылками на Sinclair as IMarried, если я разведусь?
Дома подумал и придумал, что в таком специальном случае мы не убираем из списка реализуемых интерфейс IMarried, а добавляем IDivorced. (В предположении, что динамическое добавление мы уже реализовали).
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Дома подумал и придумал, что в таком специальном случае мы не убираем из списка реализуемых интерфейс IMarried, а добавляем IDivorced. (В предположении, что динамическое добавление мы уже реализовали).
А что с динамическим удалением делать? Если ты поменял статус и уже реализуешь интерфейс IDivorced, то методы IMarried, по идее, должны быть уже не доступны.. Скажем метод Sinclair.AskWifeToMakeBreakfast(Omelette), должен, как минимум, сгенерить исключение...
Здравствуйте, Sinclair, Вы писали:
S>Что значит "переименовать"? Я не ICanBeMarried. Я уже IMarried. У меня и IPerson IMarried::Spouse есть. Вопрос в том, что делать со ссылками на Sinclair as IMarried, если я разведусь?
Попахивает тем, что IPerson будет расширятся интерфейсом IAdultPerson с возможностью хранения History женитьб/замужеств и возможностью производить других IPerson
)
).
. К счастью, религиозный период а программировании я уже прошел. Особых разногласий с Вами не имею.
— Ну и фиг с ним, полками обойдёмся..."
Мы уже победили, просто это еще не так заметно...
