ИМХО ты говоришь неверно.
Если какое-то поведение определено в родительском классе, оно по умолчанию переходит в класс-потомок - в этом и есть смысл наследования !

Правильно, это и есть часть наследования - возможность обращения к свойствам базового класса из класса-наследника

Пусть автор дает развернутый вопрос.
Мы долго можем телепатировать

Попробую поставить вопрос немного иначе. Пусть есть код:
[code]
// класс Б1

Перем Поле Экспорт;

Процедура Конструктор()
    Поле=0;
КонецПроцедуры

Процедура ПриПолучении_Поле(_Значение)
    _Значение=Поле;
КонецПроцедуры

Процедура ПриЗаписи_Поле(_Значение)
КонецПроцедуры

// класс Н1 : Б1 (т.е. потомок Б1)

Функция Я(Конт) Возврат Конт КонецФункции

Процедура Конструктор()
    Я(Контекст).Поле=1387;
КонецПроцедуры
[/code]

В этом примере конструктор класса Н1 не сможет проинициализировать нужным значением унаследованный реквизит Поле, т.к. отработает метод ПриЗаписи его суперкласса.

Т.е. выходит, что суперкласс относится к коду своего наследника как к клиентскому. Получается, что наследование в 1с++ -- это вариант композиции, при котором все сообщения наследнику по умолчанию транслируются базовому классу. Мне кажется, это не совсем то, что подразумевается под наследованием в ООД.

[quote author=kbakaras link=1162972361/0#5 date=1162986421]
Т.е. выходит, что суперкласс относится к коду своего наследника как к клиентскому. Получается, что наследование в 1с++ -- это вариант композиции, при котором все сообщения наследнику по умолчанию транслируются базовому классу.[/quote]
Да, именно так и получается.
Сдается мне, что ты просто хочешь организовать protected поле своими силами :)

kbakaras писал(а) 08. Ноября 2006 :: 12:01:

Вот про это расскажи плиз поподробнее.
Во-первых, что такое ООД?
Во-вторых, почему 1С++-кие иерархии классов не являются осмысленными?

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

Классы, которые можно построить на 1с++, до этой концепции не дотягивают. Из-за того, что наследование практически отсутствует в текущей реализации.

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

Сокрытие - важнейшая концепция при наследовании. И если наследник при наследовании видит в родителе только то, что должен видеть предполагаемый клиент родителя, то такое наследование даёт мало пользы. В классе должно быть как минимум 2 двери - для клиентов и для наследников. В некоторых реализациях их 3. Ещё одна - для близких (партнёров). Но без неё жить можно, т.к. она не является системообразующей.

Вот и замечательно: как только дал развернутый пример, все стало просто и понятно

1. Т.к. 1С++ базируется изначально на синтаксисе 1С, а у 1С есть два вида доступа - Экспорт(паблик) и без Экспорта (приват), поэтому и был выполнен только вариант с этими двумя видами доступа.
ИМХО Для подавляющего большинства задач такой схемы хватает.

2. Протектед-свойства/методы не столь обязательны. Конечно, с их помощью можно получить более элегантный вариант, но и без них можно проектировать нормальную систему.

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

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


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