Хотя, рассматривать методы сериализации (их поведение) как
конструкторы:
наверное
я погарячился..... (в том смысле что вызывать методы предка "автоматом", как конструкторы)
поведение методов сериализации должно бытьА) атомарным: в некотором предке должны быть реализованы (можно "пустышкой", виртуальные методы)
все 3 интерфейса (иначе - ни одного, сериализация не используется)
Б) если хотим наследовать сериализацию:
все 3 метода в предке должны быть объявлены как ЭКСПОРТ
(иначе все - приватные, без ЭКСПОРТ)
В) в наследнике (если нужно) можно переопределить как 1 так и все 3 метода предка
те, что НЕ были переопределены - берем из предка
Г) наследник должен переопределять методы предка (ЭКСПОРТ-ные)
с директивой ЭКСПОРТ
Д) если наследник переопределяет методы предка без ЭКСПОРТ
- то он должен переопределить ВСЕ 3 МЕТОДА, и все - без этой директивы.
Е) если нужно вызвать метод предка - вызываем его через
"я().ПолучитьБазовыйКласс(ИмяПредка).ИмяМетода()"
т.е. как обычно....
Ж) если прикладному программисту нужно не просто восстановить объект,
а как-то его предварительно инициализировать,
то он вполне может самостоятельно вызвать
я().Конструктор() т.е. мысль о том, что "
При восстановлении объекта из строки - конструктор не вызывать"
абсолютна правильная, т.к. восстановленный объект - "уже взрослый"
без предварительных инициализаций....
При этом: 1)
логика сохранения/восстановления объекта должна быть отдана на откуп ПРИКЛАДНОМУ программисту.
И если он там "напортачил" с доступом к приватным переменным,
то это
проблема прикладного решения а не 1С++ (которое реализует принципы ООП).
2)
В случае ошибки доступа к приватным переменным:
должно быть вызвано исключение:
"память не может быть read/write...."
"в классе Х нет атрибута Y..."
или что-то вроде этого.....
(ошибка проектирования)...
3)
В случае "неатомарности" - сообщение (то же что выводится сейчас):
что-то вроде "Реализованы не все методы в таком-то классе ....."
и сериализация в этом классе должна отключаться......
Или тоже исключение (ошибка проектирования)...
Как-то так.
artbear писал(а) 24. Мая 2006 :: 13:49:В общем, у каждого КОП возможно описать методы, которые пока не наследуются.
Это
- _ПолучитьКод
- КлассСохраняемый
- СохранитьКлассВСтроку
- ЗагрузитьИзСтроки
- _ПолучитьКолвоДСвойств
- _ПолучитьИмяДСвойства
- _ПриЧтенииСвойства
- _ПриЗаписиСвойства
- ПриЗаписи_ИмяАтрибута
- ПриПолучении_ИмяАтрибута
- ОбработкаСобытияОтКласса
Для каких методов, по-вашему, необходимо наследование? Думаю, такое же поведение наследования должно быть и у других методов....
-------------------------------------------------------------------------------
ОБЩИЙ ПРИНЦИП НАСЛЕДОВАНИЯ
ДОЛЖЕН СОБЛЮДАТЬСЯ
БЕЗ ИСКЛЮЧЕНИЙ ДЛЯ ВСЕХ МЕТОДОВ ВСЕХ ОБЪЕКТОВ (КЛАССОВ).
-------------------------------------------------------------------------------
В противном случае:
возможны варианты
когда придется "копипастить" методы из класса в класс
а это уже не ООП......
главное помнить прикладному программисту о методах:
* вирт()
* я()
* я().ПолучитьБазовыйКласс(ИмяПредка)
* экпортный атрибут/метод или нет - у класса, к которому обращаемся....
ВОПРОС:Уважаемые авторы 1С++, можно ли ждать
поправки в конституцию ?
Т.е. следующего релиза?
Зарегил в багзиле:
http://www.1cpp.ru/bugs/show_bug.cgi?id=4562