fez писал(а) 29. Мая 2006 :: 20:03:


Вот этой фразы я не понял, хотя слова, вроде, все знаю. Даже ЗаменитьЭксзБазовогоКласса. 

А может это просто баг возник на одной из сборок?

А я в своё время вообще отказался от использования этого метода, потому как стоит лишь одно неверное телодвижение сделать, и систему валит вусмерь.
Ну его в баню. Агрегирование как-то надёжнее.

sedmin писал(а) 30. Мая 2006 :: 03:52:

Нет.

defcls.prm

класс Документы_СБухИтогами = __Документы_СБухИтогами@MD
{
    void __Инит__();
};

класс Документ_РКО = __Документ_РКО@MD : Документ.РКО, Документы_СБухИтогами
{};

класс Документ_РКО_Вексельный = __Документ_РКО_Вексельный@MD : Документ.РКО_Вексельный, Документы_СБухИтогами
{};
 

Никакого агрегирования. Только наследование.

kms писал(а) 30. Мая 2006 :: 12:36:


Более точно было бы сказать эту фразу вот так:

Цитата:

Тогда я отвечу "да". И добавлю, что заменять "какой-то из" классов иерархии в общем-то наверное и не нужно. Пожалуй всегда нужно заменять тот класс, что был изначально создан через СоздатьОбъект().

P.S. Все же утро вечера мудренее.
P.P.S. Если у кого-то все же будут возражения к моим рассуждениям - с удовольствием выслушаю.

Цитата:


Не согласен.

Только к ООП это не имеет никакого отношения, тут у тебя все правильно.
ЗаменитьЭксзБазовогоКласса - это хак над ООП.

И либо мы позволяем замену базового класса, тогда это должно работать для любого места в иерархии.
Либо нет, тогда этот метод вообще вне закона.

То что ты предлагаешь - это решение для чисто абстрактных классов, т.е. классов, которые никогда сами по себе не могут быть созданы.

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

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

kms писал(а) 30. Мая 2006 :: 12:50:

Резонно. Не, тогда ну его в пень этот хак. Конструкторы с параметрами рулят.

Пусть есть иерархия А:Б:Ц

Класс Б написан так, что он использует ЗаменитьБазовыйОбъект() в предположении, что он заменяет экземпляр класса А.

Теперь создаем класс Ц и ЗаменитьБазовыйОбъект() в классе Б начинает заменять экземпляр класса Б.

Проблема?

kms писал(а) 30. Мая 2006 :: 13:13:

А зачем классу "Б" может понадобится заменять экземпляр класса "А"? Я понимаю когда класс "Б" меняет свой экземпляр на экземпляр класса "А". А зачем нуна так как ты сказал?

kms писал(а) 30. Мая 2006 :: 13:37:

Метод должен заменять не для класса, а для объекта.

Цитата:

Экземпляр_Б = СоздатьОбъект("Б");
Экземпляр_Б.ЗаменитьЭксзБазовогоКласса("А", ОбъектКласса_А);
 

Все правильно? Вопросов не возникает? Иерархия не нарушена?

Метод применяется к ОБЪЕКТУ. Конкретному объекту класса. Мы заменяем экземпляр данного конкретного объекта на экземпляр ДРУГОГО класса. И иерархии это не нарушает.

И я хочу, чтобы вне зависимости от того, где именно в иерархии располагается вызов метода ЗаменитьЭксзБазовогоКласса(), происходило именно это. Чтобы брался объект, созданный с помощью СоздатьОбъект() (а уж будет это "А", "Б" или "Ц" - нас не колышет), и именно этот объект подменялся на объект ДРУГОГО класса. Какого именно класса, и какой именно объект - будет указано в параметрах метода ЗаменитьЭксзБазовогоКласса().

kms писал(а) 30. Мая 2006 :: 14:02:

Не надо, я понял.

Прочитал все, что вы написали - ничего не понял

Метод нужный и верный, пока у нас не будет конструкторов с параметрами.

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

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

fez писал(а) 30. Мая 2006 :: 14:20:


ОК. На примере твоей иерархии, только Документы_СБухИтогами я тоже унаследую от Документ.РКО (для примера, это просто абстракция)

класс Документ_РКО = __Документ_РКО@MD : Документ.РКО,  Документы_СБухИтогами
{};

класс Документы_СБухИтогами = __Документы_СБИ@MD : Документ.РКО
{};
 

ДокСБИ = СоздатьОбъект("Документ_СБухИтогами");
ДокСБИ.Инит(__Конкретный_РКО);

Документ_СБухИтогами::Инит(__Конкретный_РКО)
{
ЗаменитьБазовыйОбъект("Документ.РКО", __Конкретный_РКО);
}
 

Т.е. Документ_СБухИтогами полагает, что он работает с конкретным объектом РКО.

ДокРКО = СоздатьОбъект("Документ_РКО");
ДокРКО.Инит(__Конкретный_РКО_2); // наследованный метод
 

Я утверждаю, что Инит() должен по-прежнему заменять базовый объект класса "Документы_СБухИтогами".

Ты предлагаешь заменять базовый объект класса "Документ_РКО".

Здесь 2 проблемы:
1. Код класса Документы_СБухИтогами начинает работать по-другому, это то, о чем я писал в самом начале. Это источник ошибок.
2. В принципе, Документы_СБухИтогами ничего не обязан знать о каких-то там наследниках. Это принципиально.

kms писал(а) 30. Мая 2006 :: 14:44:

Плохая абстракция. Зачем нам классу Документ_РКО два суперкласса Документ.РКО? Почему в таком случае нельзя наследовать Документ_РКО только от Документы_СБухИтогами?

Пока примера не понял, давай другой.

(бурчит под нос) Давайте теперь еще зациклим иерархию классов...

Цитата:


Да какая разница.
Ну давай унаследуем Документы_СБухИтогами от Справочник.Товары.
Что изменится?

ЗаменитьЭкзБазовогоКласса внутри Документы_СБухИтогами должен работать с иерархией класса Документы_СБухИтогами и ни с какой другой!

Он не должен ничего знать про Документ_РКО и про Документ.РКО, или это уже не ООП.

artbear писал(а) 30. Мая 2006 :: 15:09:

Неправильно это!

kms писал(а) 30. Мая 2006 :: 15:08:

Пойду подумаю над этим...

Это да, ничего криминального нету.
Ты дальше рисуй иерархию.
У тебя дальше что-то будет наследоваться?

artbear писал(а) 30. Мая 2006 :: 15:20:

Иерархия крайне простая:

Документы_СБухИтогами : Справочник.Товары
Документ_РКО : Документ.РКО, Документы_СБухИтогами.

Все законно?

Предложение Федора:
fez писал(а) 30. Мая 2006 :: 13:17:


10 минут что-то растянулись, вы не находите?

kms писал(а) 30. Мая 2006 :: 15:21:


Почему не будет?

fez писал(а) 30. Мая 2006 :: 15:28:

Если ЗаменитьБазовыйОбъект() будет работать для объекта класса, созданного функцией СоздатьОбъект(), то в данном случае он будет работать для класса "Документ_РКО", у которого среди базовых классов нет класса Справочник.Товары.

kms писал(а) 30. Мая 2006 :: 15:36:

Как это? Вассал моего вассала - не мой вассал? Что же это за ООП?

kms писал(а) 30. Мая 2006 :: 15:36:

Почему это нет среди базовых классов? у предка/папы есть свой папа/предок (дедушка) Спр.Товары и все нормально заменяется, в связи с иерархией.
Иерархия - это же не один уровень, а несколько

Суперкласс "Документы_СБухИтогами"
Это как?
Как построена иерархия с его участием?

artbear писал(а) 30. Мая 2006 :: 15:43:

Поменял свое сообщение с описанием всей задачи целиком.

kms писал(а) 30. Мая 2006 :: 15:47:


у меня - никак. но просто потому, что я не создаю объектов типа Документы_СБухИтогами. Если бы создавал - тогда я бы знал, какое поведение я хочу увидеть от этого метода.

artbear писал(а) 30. Мая 2006 :: 15:50:

"...а с самого низа иерархии". Базовые классы сверху, подчиненные снизу.

kms писал(а) 30. Мая 2006 :: 15:52:


Нет, не понимаю.
Почему для вызова метода Вид() класса Документ.РКО мне не нужно передавать объект _Сам? Почему для Вид() я могу обойтись работой через Сам(Контекст) ?

P.S. Ну то есть я понимаю, что твой вариант скорее всего заработает. Но почему мой вариант неправильный с точки зрения ООП?

artbear писал(а) 30. Мая 2006 :: 15:56:

Приведи пример.

Да, пока у нас нет виртуальных функций, подобное поведение можно считать ошибочным.

artbear писал(а) 30. Мая 2006 :: 16:06:

У нас все функции - виртуальные.

Обновил пример, описывающий проблему. Вид() будет работать всегда и везде, это я ступил. Заменил вызов Вид() на обращение к реквизиту Фирма.

Просто Deb'у западло было делать нормальную инкапсуляцию. Ну, сложно это, да и зачем.
Но это не значит, что это соответствует ООП.

kms писал(а) 30. Мая 2006 :: 16:36:

На C++ не умею, я вот на питоне написал.

class Base:
	def PolimorphMethod(self):
		self.MethodFromTheChild()

class Child_One(Base):
	def MethodFromTheChild(self):
		print "child one"

class Child_Two(Base):
	def MethodFromTheChild(self):
		print "child two"


One = Child_One()
One.PolimorphMethod()

Two = Child_Two()
Two.PolimorphMethod()
 

печатает

Цитата:

Цитата:

ОК, щас сам напишу.

kms писал(а) 30. Мая 2006 :: 16:49:

А что, у нас С++ - это эталон ООП?

Цитата:

Давно пора. Ты еще вчера говорил, что ты "не в теме".

Вот код на С++:
Цитата:

Печатает, понятное дело, "child", "child".

Всего лишь одно отличие:
Метод meth() чисто виртуальный. А класс base - чисто абстрактный класс.
Соответственно, контроль ошибок - реальный, а не призрачный.

С++ эталон? Не знаю. Но то, что ты написал на питоне - это ужасно.
Впрочем, если тебе не важна правда и ты хочешь остаться при своих - пожалуйста.

P.S.
Код, который ты продемонстрировал - крайне небезопасный. Более того, в 1С ты это можешь отследить исключительно на этапе выполнения.
Я такой код не поддерживаю и поддерживать кого-либо (даже тебя!) в его использовании не собираюсь.

И, напоследок, загляни вот сюда: http://skipy.dev.juga.ru/philosophy/inheritance.html
Не ты ли эту ссылку давал? Или это Палыч был?

Отлично написано, лучше не скажешь.
Прочитай про наследование реализации и наследование интерфейсов, как это сделано в java (в С++ так же).
Если ты поймешь, почему так сделано, у тебя не останется вопросов в отношении того, как должна работать замена базовых объектов в 1cpp.
И почему метод (Проведен()?) или свойство (Фирма?) наследника, которые видны в базовом классе без явного определения интерфейса - это плохо.

Очень, очень плохо.

P.S.
И твоя ошибка в том, что ты путаешь наследование реализации (а в 1С/1cpp это именно так) с наследованием интерфейсов.
При этом не имея никакого желания интерфейс этот определять и забивая болт на понятие инкапсуляции вообще.

DrACe писал(а) 31. Мая 2006 :: 03:26:

Да уж. Тема вызвала прилив сил

В отношении ЗаменитьЭксзБазовогоКласса().

Это не виртуальная функция. Да, она определена для каждого класса.
Но это не виртуальная функция. Это, если хочешь, служебная функция.
Она нужна исключительно для конструирования иерархии в 1С.

Ее поведение должно быть детерминировано и здесь я против какого бы то ни было полиморфизма.

Я уже объяснял почему.
Если ты переопределил любую функцию в подклассе, проблемы не будет.
Ну возвращал у тебя Вид() "Круг", стал возвращать "Квадрат" какие проблемы?
"Переопределение" же ЗаменитьЗксзБазовогоКласса в корне изменит поведение суперкласса, если тот полагается на определенную работу ЗаменитьЭксзБазовогоКласса().

И я понимаю твое желание ее переопределить, поскольку фактически у тебя класс является чисто абстрактным (просто ты не сразу в этом признался).
Для чисто абстрактного класса переопределить ЗаменитьЭксзБазовогоКласса() было бы возможно.
Одна проблема: у нас нет поддержки абстрактных классов в 1С/1CPP.
Значит, обязательно найдется кто-то, кто возьмет твою иерархию, не разобравшись, где классы абстрактные, где нет, инстанциирует объекты абстрактных классов и получит труднонаходимые, но конкретные грабли.

Короче, без поддержки абстрактных классов, я конкретно против виртуализации ЗаменитьЭксзБазовогоКласса().
А вот не сделать ли поддержку абстрактных классов - это вопрос, над которым нужно подумать.

Здесь я вижу одну проблему: контроль ошибок на этапе компиляции будет невозможен.
Т.е. мы добавим себе работы по контролю обязательного определения чисто виртуальных методов на этапе выполнения.

kms писал(а) 31. Мая 2006 :: 09:43:


Вы были правы, доктор. Признаю себя ослом и жду дальнейших распоряжений. (с) мультик "Остров сокровищ".

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

Но все же остается пара моментов:

1. Что будет возвращать ТипЗначенияСтр(Сам(Контекст)), если ее написать в модуле Документы_СБухИтогами?
Если "Документ_РКО", то почему вызов Сам(Контекст).ЗаменитьБазовыйОбъект(НовыйОбъект) работает не так, как ожидалось?

2. Относительно виртуальных методов. Надо признать, что в скриптовых языках, таких, например, как Питон, все методы являются виртуальными. Это только с строгих языках, таких как С++ и Ява введены механизмы, которые позволят отслеживать подобные вещи. Язык 1С и 1С++ (не надо лукавить) надо отнести к нестрогим скриптовым языкам.
И надо оставить в отношении виртуальных методов все как есть, и не считать их появление и использование багом.

В чем тогда разница в результате вызова Сам(Контекст) в модулях Документы_СБухИтогами и Документ_РКО?

sedmin
Тут у меня мнение совпадает с мнением Артура (зачеркнутым).

Здесь, правда, возможны варианты.
Если рассматривать концепцию абстрактных классов, то я не против рассмотрения ТипЗначенияСтр() и ЗаменитьБазовыйОбъект() как чисто виртуальных и, соответственно, возможности их переопределения.

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

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

Цитата:

До появления 1CPP 1С был чисто объектным и братья Нуралиевы на семинарах задавали сакраментальные вопросы типа "ну, давайте, расскажите нам, что такое ООП и зачем оно вам нужно".
Сейчас мы имеем первичную реализации логики ООП, которая имеет определенные нарушения принципов ООП.
Другое дело, что мы привыкли к этой логике и готовы ее защищать. Потому что это удобно.
В этом есть здравый смысл. Вообще, по концепции ООП и эффективности ее конкретной реализации можно ведь говорить долго.
Меня, если честно, до сих пор поражает список литературы, приведенный Бучем в его книге. Там примерно 50 листов.

Однако дело не в механизмах, которые введены в С++ (С++, кстати, гибок именно за счет позднего связывания), а в нашем решении.
Мы можем сделать проще (хоть вообще все классы в один контекст объединим с произвольным доступом к методам и свойствам).
Мы можем приблизиться к классической схеме ООП и механизмы контроля мы можем обеспечить не хуже, чем в С++.
Правда, только на этапе выполнения.

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

kms
Во завернул.
Вроде и ничего против не сказал. Но даже как-то неудобно стало.
Буду изучать твою писанину.