artbear писал(а) 17. Марта 2008 :: 06:11:

А в чем принципиальное отличие переопределения свойства от переопределения метода?

Я с ходу могу утверждать, что у меня в конфигурации есть 2-3 места, где это используется.

kms писал(а) 17. Марта 2008 :: 08:30:

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

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

Сначала наследуемся от Документ.ВидДокумента, так что если в документе есть реквизит - он найдется первым. Если нет реквизита - будет использовано свойство класса.

fez писал(а) 17. Марта 2008 :: 08:46:

Ну да, я себе примерно такую схему с конструированием иерархии из сущестувующих контекстов и представлял, конечно.

Тогда такой чуть параллельный вопрос.
Берем иерархию, в которой публичный реквизит базового класса переопределен публично же в подклассе.
В базовом классе (ну, например, в одном из методов базового класса) мы к какому свойству/реквизиту будем обращаться?
К свойству базового или "полиморфно" к свойству наследника?

kms писал(а) 17. Марта 2008 :: 08:55:

В теории конечно же должно обращаться "полиморфно" к свойству наследника. Как на самом деле обстоит дело в 1С++ я доверяю проверить тебе, а в питоне ща посмотрю.

fez

Ну в общем, понятно.
Питонизированное ООП по самые небалуйки.

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

Ну да, Артур, тут вот такая схема реализации ООП, питоноподобная.
Я бы ее окончательно раскритиковал, да Федор все ее к питону примеряет - а там так же


_{Ну, с точки зрения ООП - она не правильная, ибо тут нарушения инкапсуляции на каждом шагу.
Наличие или отсутствие у базового класса наследника не должно влиять на инвариантное поведение самого базового класса - а оно влияет, ибо можно переопределить "полиморфное" свойство, и сделать его, к примеру, другим типом - и базовый класс получит проблемы при работе с этим свойством.
С++ позволяет скрывать имена свойств и методов (невиртуальных), но никакого полиморфизма в этом случае в базовом классе не возникает.
Инварианты класса остаются инвариантами... Должны оставаться - при нормальном дизайне.}


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

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

Вот нравятца мне такие посиделки, как в старые добрые времена.

fez писал(а) 17. Марта 2008 :: 13:30:


И то дело.
Надо договориться, что есть стандартное понимание ООП.
У Буча есть про полиморфизм свойств, как думаешь?

Цитата:


Боюсь, тут не все так просто.
Если суперкласс даже объявит свое свойство приватным, а подкласс - переопределит публичным, боюсь сейчас суперкласс все равно получит публичное свойство подкласса.

Ну да ладно.
У меня есть предложение: а вот найди где-нибудь подтверждение обоснованности доступа из суперкласса в суперкласс, связанных только общим подклассом (в части публичных методов и свойств) и из суперкласса в подкласс (в части публичных "невиртуальных" методов и свойств) с точки зрения теории ООП.

Т.е. давай выясним не то, можно ли использовать эту схему - или нельзя. Можно - мы же используем.
А именно ответим на вопрос - как ложится такая схема на классическую теорию ООП.