Здравствуйте, Merle, Вы писали:
M>А что с динамическим удалением делать?
M>Если ты поменял статус и уже реализуешь интерфейс IDivorced, то методы IMarried, по идее, должны быть уже не доступны..
Так вот собственно это и есть попытка ответить на вопрос "что с динамическим удалением делать?". Идея именно в том, что удалять — невозможно. Т.е. мы и потом сможем выполнять приведение Sinclair as IMarried.
M>Скажем метод Sinclair.AskWifeToMakeBreakfast(Omelette), должен, как минимум, сгенерить исключение...
По идее да. Потомка от IllegalStateException.

Здравствуйте, Dimonka, Вы писали:
D>Попахивает тем, что IPerson будет расширятся интерфейсом IAdultPerson с возможностью хранения History женитьб/замужеств и возможностью производить других IPerson
Не, ну тут все как бы от предметной области зависит. Если мы моделируем антропологию, то марьяж никого не интересует. А если финансы — то интересует не столько воспроизводство, сколько иждивение и прочие развлечения.

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

S>>Дома подумал и придумал, что в таком специальном случае мы не убираем из списка реализуемых интерфейс IMarried, а добавляем IDivorced. (В предположении, что динамическое добавление мы уже реализовали).
M>А что с динамическим удалением делать? Если ты поменял статус и уже реализуешь интерфейс IDivorced, то методы IMarried, по идее, должны быть уже не доступны.. Скажем метод Sinclair.AskWifeToMakeBreakfast(Omelette), должен, как минимум, сгенерить исключение...

Угу, и потом это исключение повсеместно ловить и далее вызывать по цепочке:

Sinclair.AskMistressToMakeBreakfast(Omelette)
Sinclair.AskGirlFriendToMakeBreakfast(Omelette)
Sinclair.AskSelfToMakeBreakfast(Omelette)
Sinclair.AskSomebodyToOrderBreakfast(Omelette)

естественно с ловлей соответствующих исключений .

Здаецца мне, просто попросить в начале интерфейс и дернуть за его метод — не самый лучший вариант решения такого рода проблемы.
Лучше уж сразу задать вопрос Синклеру-объекту на предмет наличия соответствующего метода, потому как он уж точно знает свое текущее состояние и, в крайнем случае, зная того, кто просит, сам может продиспатчить вызов до AskSomebodyToOrderBreakfast. А это как-то на СмолТок сильно смахивает.

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

V>Может быть. Насколько я понимаю, с атрибутами проблем не будет, но пока не понятно, можно ли на Питоне сделать хитрую отработку методов (см. "Реализации интерфейсов при множественной классификации"). А в этом вся соль.

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

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

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

ГВ>Стоп! Первые два балла. Задача — модель предметной области. Совет N0 — никогда не моделируйте данные. Моделируйте предметную область.

Ок, понимаю что Вы имеете в виду. Это вопрос терминологии, конечно. Как Вы могли убедиться далее, я именно и пытался моделировать предметную область. Тем не менее, замечание точное и ценное.

ГВ>В корне неверно. Люди (Person) могут находиться по отношению к тем или иным подсистемам в тех или иных ролях. Роль — суть независимый объект предметной области.

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

B>>class Applicant {
B>> public Applicant applicant; // Имелось ввиду public Person person? — ГВ


B>>}
B>>[/ccode]
Сорри, очепятка. Имелось в виду

class Applicant {
  public Application application;
}

ГВ>Да прекратите Вы привязываться к "чёткой иерархии классов", которая ничего кроме путаницы не вносит. Давайте утвердимся в мысли, что иерархия — сугубо технологическое понятие. В реальной предметной области как правило можно выделить подобные по структуре элементы и на основании выделенного подобия построить некоторую иерархию. Но и не более того. Ответьте себе на вопрос — а зачем обязательно притягивать за уши иерархию?
Вот это меня жутко позабавило. Немного истории, откуда есмь полезли все эти проблемы.
Дело было так. Раньше я всегда работал с РСУБД для хранения данных и в таких условиях ОО иерархии действительно ничего кроме технологического момента не вносят. А тут под свою задачу, я, наивный, написал ООБД и радуюсь сижу — вот, мол, щас забабахаю крутую иерархию, и будет все пучком. Ан нет, не тут то было, как оказалось... Обидно, получается зря ООБД писал ??? Скока усилий зря...

ГВ>Да. всё верно. Можно изменить класс. Но как насчёт того, чтобы ИЗМЕНИТЬ МНОЖЕСТВЕННОСТЬ отношения экземпляров? Нам известно, что User определён для некоторого одного пользователя, Applicant — тоже. А что насчёт того, что один User может быть юзером в нескольких местах или подателем нескольких разновидностей заявлений?
Вот, опять мы возвращаемся к старой доброй реляционной модели...Хоть это все и верно, я все больше печалюсь.

ГВ>Да. И на будущее — НЕ ЧИТАЙТЕ НА НОЧЬ АДЕПТОВ ООП! И утром не читайте. И вообще не читайте.
Ну, как всегда, практика оказалась в отрыве от теории

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

E>

E>def promote(obj, klass):
E>    class NewClass( obj.__class__, klass):
E>            pass
E>        obj.__class__ = NewClass
E>

Обнаружилось одно очень неприятное обстоятельство — таким образом сделанные классы нельзя пиклить (сериализовать). Оно и понятно — они ж ни в каком модуле не определены!
Короче есть, конечно, заплатка, но блин сложная и потенциально глючная очень. Я в печали.

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

S>Так вот собственно это и есть попытка ответить на вопрос "что с динамическим удалением делать?". Идея именно в том, что удалять — невозможно. Т.е. мы и потом сможем выполнять приведение Sinclair as IMarried.
M>>Скажем метод Sinclair.AskWifeToMakeBreakfast(Omelette), должен, как минимум, сгенерить исключение...
S>По идее да. Потомка от IllegalStateException.
Угу, но тут вылезает тот факт, что для правильной генерации такого исключения методы IMarried должны, прямо или косвенно, знать о возможности появления метода IDivorce, что не гуд.

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

S>Смущает меня только один вопрос. Вот взяли мы и сохранили где-то ссылку на полученный таким образом IMarried. Как выполнить развод? Фишка в том, что добавление ролей никак не нарушает типизации. В системах со сборкой мусора персона просто не сможет получить развод, пока хоть кто-то знает о том, что она была жената.
S>Хотя это, скорее, общефилософский вопрос к системам с динамической классификацией: как быть в случае отказа от исполнения роли?

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

Если же да (то есть, персистентная достоверность информации критически важна), для этого придуманы специальные механизмы.
Централизованные службы регистрации изменений персонального состояния! По-простому ЗАГС
Именно там и только там должна храниться информация о семейном положении.
Соответственно, спрашивать интерфейс IMarried нужно не у самого человека (а вдруг он соврет), а у специальных сервисов:

public class CROffice
{
    public void    Marry   ( IPerson one, IPerson another);
    public IPerson SpouseOf( IPerson one);
}