Адреса protected полей класса

← →
Verg © (2005-03-03 20:52) [0]

Может ли (должен ли иметь право) потомок получать или передавать вовне адрес(а) унаследованного protected члена? (Может и не только адрес ни и ссылку ( var, const, reference )).
Речь не идет о конкретном ЯВУ. Вообще, в принципе.... по идее...
Я считаю, что нет.
Он относится к разряду защищенных и изменять его не членам дерева наследования или даже давать такую возможность было бы нарушением этой защиты. Пустть сам потомок манипулирует зачением этого члена как угодно, но получать его адрес ( сам факт ) создает угрозу объявленной ( заявленной ) защите.

← →
Anatoly Podgoretsky © (2005-03-03 21:04) [1]

По идеологии есть полные права на повышение статуса, вплоть до Published. Права делегированы наследнику.

← →
Shaman_Naydak (2005-03-03 21:15) [2]

если мы говорим про поля класса, то отдавать его для манипулирования вне класса-наследника вообще неправильно иделогически.
> Podgoretsky
Объясните плиз как вы собираетесь повысить видимость полю класса?

← →
Anatoly Podgoretsky © (2005-03-03 21:16) [3]

Вообще то не подумал, может и нельзя :-(

← →
vuk © (2005-03-03 21:25) [4]

Зато свойству видимость повысить можно.

← →
Verg © (2005-03-03 21:25) [5]

Сам факт получения адреса (@ или & или передача в качестве var процедуру/метод класса не наследника), вообще в, в принципе, на чем должна занканичваться защита полей класса? Может она не должна заканчиваться, тогда сам факт получения адреса защищенного члена неправомерен.
Вот интересен этот, как кажется, идеологический вопрос, но я надеюсь в ближайшее время я смогу более конкретно сформулировать конкретику, всязи с появлением новой модели компилятора C++ от MSFT, которая заставила задуматься об этом вопросе.
Некоторые считают полноценныю защиту обявленную словом protected за глюк этого компилера...

← →
wicked © (2005-03-03 21:35) [6]

afaik неправильно... но может быть использовано, как полезный трюк...

> (Может и не только адрес ни и ссылку ( var, const, reference
> )).

то есть, даже в функции RTL передавать ссылку нельзя?... через локальные переменные только?...
ср.
Val(<string>, fMyField, <err>);
и
Val(<string>, temp_var, <err>); fMyField := temp_var;

← →
vuk © (2005-03-03 21:38) [7]

Вообще говоря, все, что является protected, действительно отдается на откуп потомкам, и только от них зависит, что делать с добром, полученным в наследство. Можно наружу передавать, а можно и рыбу заворачивать. Тут уж все от разработчика зависит.

← →
Verg © (2005-03-03 21:44) [8]

"Наследство" дано с условием protected, т.е. "только сын мой, и сын твоего сына, равно со своим отцом" сможет безраздельно влавствовать над "моим богатсвом". В то же время выписка "чеков на предьявителя" должна быть категорически запрещена по определнию (protected).
А иначе нахрен было писать protected?

← →
Набережных С. © (2005-03-03 21:44) [9]

Имхо, у класса вообще не должно быть доступных извне полей.

← →
vuk © (2005-03-03 21:54) [10]

>В то же время выписка "чеков на предьявителя" должна быть
>категорически запрещена по определнию (protected).
Только вот как при этом прикажете быть со всякими функциями-утилитами? Есть protected экземпляр какого-то класса и внешняя функция, которая что-то с ним делает. Получается, что функцию вызывать нельзя (ведь получается передача наружу адреса protected данных), а можно только продублировать код ее ручками в своем методе и только потом вызывать. Получаем типа новый подход к Code Reuse? :o)

← →
Verg © (2005-03-03 21:57) [11]

> Набережных С. © (03.03.05 21:44) [9]

Пусть и так. Пусть доступ к ним идет только через методы этого класса.
Но допустимо ли (попробую на Дельфи выразить):

TMyClass = class
protected
FSomeField : integer;
public
function GetSomeFiled : PInteger;
end;

function TMyClass.GetSomeFiled : PInteger;
begin
result := @FSomeField; // На мой взгляд - нонсенс, нарушение прав
end;

Т.е. public метод "игнорирует" правило protected ! На каком основании он делегирует право разпоряжаться значением protected поля "кому попало"?

← →
Набережных С. © (2005-03-03 22:01) [12]

> vuk © (03.03.05 21:54) [10]

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

← →
Verg © (2005-03-03 22:05) [13]

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

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

← →
vuk © (2005-03-03 22:06) [14]

to Набережных С. © (03.03.05 22:01) [12]:
Чтобы внешняя функция сделала что-то с экземпляром класса (да и любыми данными), необходимо передать ей адрес этих данных. Если операцию получения адреса для protected данных считать неправомерной, то передать что-то внешней функции не представляется возможным.

← →
Набережных С. © (2005-03-03 22:07) [15]

> Verg © (03.03.05 21:57) [11]

Именно это и хотел сказать, что такое не допустимо. В идеале. В реале, к сожалению, иногда искушение пересиливает:(

← →
Набережных С. © (2005-03-03 22:12) [16]

> vuk © (03.03.05 22:06) [14]

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

← →
Игорь Шевченко © (2005-03-03 22:16) [17]

Verg © (03.03.05 21:57) [11]

Невозможно защититься от злокозненного программиста.

Точно такая же возможность допустима в С++, с, на мой взгляд, более строгим контролем видимости. Например, если для класс объявлен friend, то он может отдавать наружу private-поля класса (по ссылке на них, например), не противореча грамматике языка.
Грамматика разрабатывалась не для того, чтобы запретить всевозможные варианты обхода видимости :)

С уважением,

← →
vuk © (2005-03-03 22:16) [18]

to Набережных С. © (03.03.05 22:12) [16]:
>Если это дружественная функция, то она имеет все права.
Эт как? Функция утилита должна быть дружественной всем классам, которые хотят ее использовать?

← →
Набережных С. © (2005-03-03 22:22) [19]

> vuk © (03.03.05 22:16) [18]

А в чем проблема? Либо она должно оперировать только публичными данными.

← →
Verg © (2005-03-03 22:22) [20]

> Игорь Шевченко © (03.03.05 22:16) [17]

> Грамматика разрабатывалась не для того, чтобы запретить
> всевозможные варианты обхода видимости :)

Все верно. Но ведь именно грамматика. Если написал, что protected, то и нечего "наружу концы раздавать" обходными путями.
Никто ж за язык не тянул.
Для какого нафига написал protected? От кого protected?
Это как бесконечные const в c++, от которых по-началу стреляешься, а потом начинешь отдавать должное некоей мудрости.

← →
DiamondShark © (2005-03-03 22:24) [21]

> Я считаю, что нет.

Тогда не сметь использовать конструкции вида
SetLength(FPrivateField,...
Read(FPrivateField,...
и т.п.

← →
vuk © (2005-03-03 22:25) [22]

>А в чем проблема?
Проблема в еще необъявленных классах.

← →
У (2005-03-03 22:25) [23]

ИМХО, уровень protected не предназначен для полей.
А в основном для функций и свойств.

← →
Набережных С. © (2005-03-03 22:29) [24]

> vuk © (03.03.05 22:25) [22]

Нет, не понимаю. Пример можешь привести?

← →
DiamondShark © (2005-03-03 22:32) [25]

> Сам факт получения адреса (@ или & или передача в качестве
> var процедуру/метод класса не наследника)

Если мы говорим "не о конкретном ЯВУ. Вообще, в принципе.... по идее...", то получение адреса, и передача по ссылке -- это принципиально разные вещи.

← →
Verg © (2005-03-03 22:32) [26]

> DiamondShark © (03.03.05 22:24) [21]
>
> > Я считаю, что нет.
>
> Тогда не сметь использовать конструкции вида
> SetLength(FPrivateField,...
> Read(FPrivateField,...
> и т.п.

Точно, совершенно верно. Класс при обявлении защищенных членов должен совершенно четко обозначить права своих непотомков (путем объявления списка или модуля/класса) или вообще внеклассовых структур, имеющих, тем не менее, полный доступ к объвляемым защищенным своим полям. И только им можно передавать ссылки или указатели на свои поля.

← →
Verg © (2005-03-03 22:34) [27]

> DiamondShark © (03.03.05 22:32) [25]
>
> > Сам факт получения адреса (@ или & или передача в качестве
>
> > var процедуру/метод класса не наследника)
>
> Если мы говорим "не о конкретном ЯВУ. Вообще, в принципе....
> по идее...", то получение адреса, и передача по ссылке --
> это принципиально разные вещи.

Не вижу принципиальной разницы.

← →
Verg © (2005-03-03 22:36) [28]

Но вот так вот дозволять "вникуда отстреливать" ссылки на свои "непростые" поля.... на мой взгляд неправильно.

← →
Anatoly Podgoretsky © (2005-03-03 22:39) [29]

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

← →
DiamondShark © (2005-03-03 22:39) [30]

> Класс при обявлении защищенных членов должен совершенно
> четко обозначить права своих непотомков

А зачем? Чтоб "в гамаке и на лыжах"?
Класс прекрасно осведомлён о своих приватных членах, и вправе делать с ними что угодно.
Зачем придумывать механизмы, которые не будут работать?
Ну хорошо. Запретим мы внешним процедурам доступ по ссылке к приватным полям. А толку? Оператор присваивания мы тоже будем запрещать или отдельно декларировать? Кто запретит вместо
read(FPrivateField);
написать
read(LocalVar); FPrivateField := LocalVar;?
Никто. А что мы выиграем в идеологии, кроме лишнего гемора и усложнения компилятора? Ничего.

← →
vuk © (2005-03-03 22:39) [31]

to Набережных С. © (03.03.05 22:29) [24]

>Нет, не понимаю. Пример можешь привести?

procedure UtilityProc(Instance: TSomeClass);
begin
//что-то делаем с Instance
end;

TSomeOtherClass = class
...
protected
FSomeInstance: TSomeClass;
procedure SomeMethod;
end;

procedure TSomeOtherClass.SomeMethod;
begin
...
UtilityProc(FSomeInstance);
...
end;

потом, где-то в другом месте, через пару лет

TMyClass = class(TSomeOtherClass)
procedure MyMethod;
end;

procedure TMyClass.MyMethod;
begin
...
UtilityProc(FSomeInstance);
...
end;

Если нельзя получать адрес protected полей, то вызов UtilityProc неправомочен (туда экземпляр передается). Если же UtilityProc каким-то образом должна являться дружественной к классу, который ее вызывает, то она обязана быть дружественной к еще необъявленным классам. Вот отсюда и вопрос. Эт как?

← →
vuk © (2005-03-03 22:41) [32]

А вообще если идти до конца, то все, что не public, нужно делать private, а наследование запретить как класс. Чтобы неповадно было. :o)

← →
DiamondShark © (2005-03-03 22:43) [33]

> Verg © (03.03.05 22:34) [27]
>
> Не вижу принципиальной разницы.

Адрес -- понятие машинное, implementation dependent.
Ссылка -- чисто концептуальное. Оно даже абстракнее, чем, скажем, такая тривиальная вещь, как "целое число".

← →
DiamondShark © (2005-03-03 22:46) [34]

Да, кстати, о protected полях.
Protected -- это интерфейс разработчика.
Т.е. предполагается, что он опубликован и документирован.
Так что наследник с protected имеет полное право обращаться так же, как и со своими private.

← →
DiamondShark © (2005-03-03 22:47) [35]

> vuk © (03.03.05 22:41) [32]

Вообще-то, да.
Мне в этом плане Zonnon нравится.

← →
Verg © (2005-03-03 22:50) [36]

> DiamondShark © (03.03.05 22:39) [30]
>
> > Класс при обявлении защищенных членов должен совершенно
>
> > четко обозначить права своих непотомков
>
> А зачем? Чтоб "в гамаке и на лыжах"?
> Класс прекрасно осведомлён о своих приватных членах, и вправе
> делать с ними что угодно.
> Зачем придумывать механизмы, которые не будут работать?

Да. Нахрен ж тогда protected вообще. Да и вообще разграничение public/protected/public ?
Да и const, который по-моему только с D6 опомнились и запретили модифицировать.

Но уж если "назвались", то извиняйте - не ты назвал protected (речь о наследниках) - не тебе лезть к этим полям с такими "попытками несанкц. доступа".

← →
Anatoly Podgoretsky © (2005-03-03 22:58) [37]

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

← →
DiamondShark © (2005-03-03 23:01) [38]

> Нахрен ж тогда protected вообще

Интерфейс разработчика.

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

← →
vuk © (2005-03-03 23:07) [39]

to DiamondShark © (03.03.05 22:47) [35]
Наследование, вроде как, там не отменяли... :o)

> vuk © (03.03.05 23:07) [39]

Наследуются только интерфейсы.
Для code reuse пожалуйте использовать агрегацию.

http://zonnon.ethz.ch/papers/Zonnon_Language_Report_v02r02_2_y041101.pdf

> vuk © (03.03.05 22:39) [31]

> vuk © (03.03.05 22:39) [31]

Да, здесь есть определенный резон. И все же. Нам нужна утилита для работы с TSomeClass? Извольте. Делаем потомка от TSomeClass и у него определяем метод - вместо UtilityProc метод класса. Не предусмотрели при разработке TSomeClass? А кто виноват?:)
Все-таки здесь работу с внутренним полем определяет автор класса, ведь UtilityProc к тому моменту уже существует и автор знает, что она делает. Выставлять наружу внутреннюю переменную - другое дело. Возможно ты и прав, не стоит ограничивать здесь свободу, скорее собственная аккуратность требуется. А лучше просто не строить таким образо классы. Почему TSomeOtherClass не может предоставить возможности для вызова UtilityProc, если он считает это допустимым для своих защищенных членов. Хотя с внутренними объектами, конечно, не все однозначно.

> Anatoly Podgoretsky © (03.03.05 22:58) [37]

Есть защита и должна быть. начиная от const, protected, private и прочими static_cast, dynamic_cast, as, is и т.д.
Если они (защиты) не нужны какому-либо конретному индивидуму, то, вроде бы, не об том была и речь. Ну не применяй, да и только! Вот проблем-то!
Опят же вопрос - за каким хреном наприсал protected, если никакого протектед тебе не надо на самом деле?

> DiamondShark © (03.03.05 22:43) [33]
>
> > Verg © (03.03.05 22:34) [27]
> >
> > Не вижу принципиальной разницы.
>
> Адрес -- понятие машинное, implementation dependent.> Ссылка -- чисто концептуальное. Оно даже абстракнее, чем,
> скажем, такая тривиальная вещь, как "целое число".

Кто тебе такое сказал? :)

Машинное оно или нет, концептуальное ли - это зависит от того, как давно ты бросил программить на асме и понимать похожие слова в однобоком ключе.
Оттуда тянутся, между прочим ветренно-легкие преобразовния integer(pointer) и наоборот (ну хочешь про ссылки? то integer(@reference) - те же яйца, вид сбоку).
Одним словом - что, у кого заскорузло в голове, тот так и расценивает "адрес".

> Verg © (03.03.05 22:34) [27]

Ну в Си указатель и ссылка - вещи вроде разные. Или я отстал?

> DiamondShark © (03.03.05 23:16) [40]

По-моему пока еще никто не доказал, что это единственно правильный подход для всех времен и народов:) Наследование интерфейсов имеем в COM, есть в этом и плюсы, и минусы, имхо.

Ну все, я пошел спать:)

Тема опять не туда пошла, по-моему.

Мне кажется, что право на получение адресов (ссылок на) имеют (должны иметь) только методы класса, объявленные в том же "кольце" защиты или наследующие эту защиту, что и сами эти поля, если предком (непосредственным родителем) специально не оговорено иного.

Иначе весь смысл объявления защищенных полей полей теряет смысл.

"Видим" и "доступен" - это должно быть синонимом или нет?
Если невидим, то и недоступен? Если это синонимы, то должен ли компилятор пресекать попытки любым способом нарушить эту синонимичность?

> всязи с появлением новой модели компилятора C++ от MSFT

что это за компилятор такой?
вообще, что касается с++ - то там все просто.. есть стандарт 98-го года, и не плого бы компилятору его придерживаться

> Некоторые считают полноценныю защиту обявленную словом protected
> за глюк этого компилера...

имхо и правильно.. что мне исходники править для каждого нового компилятора??

я считаю есть правила - это жестко, их придется придерживаться...
а есть идеалогия, она в программированиивсегда носит рекомендтельных характер. время КПСС прошло :)

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

если у меня класс содержит строку, которую я объявлю ес-но в приват-секции и доступ к ней у меня тоже только приват-методами?

почему я не могу вывести указатель на нее типа const char * ? (да хоть бы и char *)

по-моему здесь другая идеалогия: класс - это единое целое, внутри которого доступ противопоказано ограничивать..

IMHO:

Если поле зачем-то помещено в protected, то значит наследник имеет права бесконтрольно его изменять.

Если требуется обеспечить protected-доступ к полю без возможности работать с ним как с полем, то следует описать его в private, а в protected добавить свойство для доступа к нему.

Protected несмотря на название ни от кого не "защищает", а прячет для удобства. Написав наследника какого-л класса легко получить доступ к protected откуда угодно из модуля.

Кстати, даже на private поле может быть получена ссылка.

([D7] - компилится, выполняется)

procedure TForm1.FormCreate(Sender: TObject);
var I: PInteger;
begin
I := @Tag;
I^ := $12345678; // бесконтрольно меняем private св-во
Caption := IntToHex(Tag, 8);
end;

Verg © (03.03.05 23:52) [44]

А погляди, как сделано в C# или в Delphi .Net, там указателей и прочей некошерной нечисти нету :)

С уважением,

И я выскажу свое IMHO. Я думаю что protected - означает защищено от внешних глаз (от пользователя, юзающего этот класс по прямому назначению), но доступно для самого класса и его потомков для обеспечения работы класса по заданному алгоритму. Бегло прочитав ветку, честно говоря, так и не понял, какую идеологию преследуют собеседники, зацепившись за перевод слова protected. Ну обозвали буржуи так. Это же не значит, что protected поле, получив однажды значение, ни при каких обстоятельствах не должно его изменять, мол, я защищенное от изменения. Или "Даю только своим"? Абсурд. Что же касается адресов - то не пофиг ли? Если программисту надо передать адрес во вне, например, в API функцию, то пусть передает. Это его забота, потому что если он в каком-то месте имеет доступ к каким-то полям, то он имеет полное право распоряжаться как захочет, и несет за свои действия полную ответственность.

← →
XP (2005-03-04 07:51) [49]

Поля данных по идеологии ООП рекомендуется делать всегда private.
Причина банальна - поля данных описывают состояние экземпляра класса на данный момент.
Любые неконтролируемые изменения в полях данных могут привести к тому, что поведение объекта не будет соответствовать поведению, задекларированному разработчиком.
Единственное, что отсюда истекает, это факт того, что
любые поля данных, изменения которых должны вызывать своевременное изменение состояния объекта, не могут быть изменены произвольно, без ведома самого объекта.
Причем, при наследовании, поведение объекта (в случае изменения полей данных) может меняться (ограничиваться) разработчиком (возможно, не знающим вас, и полагающимся на четкое следование вам принципов ООП), поэтому приходим к банальному выводу - отдавать поля данных для неконтролируемого изменения - неправильно.
Именно поэтому и существует такая оригинальная конструкция в Delphi, как
property SomeProperty: byte read FSomeDatum write FSomeDatum.
А существует она именно потому, что позволяет ~потомкам класса~ контролировать доступ к полям данных путем переопределения этого свойства.

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

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

XP (04.03.05 7:51) [49]
А почему, собственно, предок должен запрещать мне делать что-то, если я вижу исходный код, знаю досканально алгоритмы работы класса? Почему мне нельзя управлять кодом класса-предка с помощью изменения значения полей, для того, чтобы получить нужную мне функциональность, тем более, если предок сделал их мне доступными?

to Набережных С. © (03.03.05 23:16) [41]:
>Делаем потомка от TSomeClass и у него определяем метод - вместо
>UtilityProc метод класса.
Ну я и говорю, новый, или, если точнее, старый подход к code reuse. Заключается в отсутствии этого самого Code Reuse. Вместо того, чтобы использовать существующий код, дублируем его.

>Не предусмотрели при разработке TSomeClass?
TSomeClass И UtilityProc написаны разными людьми в разное время. Друг о друге и о том, что кому понадобится они ничего не знали. Или, того хуже, UtilityProc вообще не имеет отношения к функционированию TSomeClass.

>А кто виноват? :)
Природа виновата, конечно же. Не сделала людей телепатами. :o)

> vuk © (04.03.05 11:16) [51]

> Ну я и говорю, новый, или, если точнее, старый подход к
> code reuse. Заключается в отсутствии этого самого Code Reuse.
> Вместо того, чтобы использовать существующий код, дублируем
> его

Что-то я такого в своем посту не разглядел. И вот почему:

> TSomeClass И UtilityProc написаны разными людьми в разное
> время. Друг о друге и о том, что кому понадобится они ничего
> не знали. Или, того хуже, UtilityProc вообще не имеет отношения
> к функционированию TSomeClass

Это как это?
procedure UtilityProc(Instance: TSomeClass);
Автор UtilityProc не знал о существовании TSomeClass? Интересный вариант:) А создатель TSomeOtherClass не знал о существовании UtilityProc? Вероятно, это был супертелепат, раз сумел при этом написать такой код

> procedure TSomeOtherClass.SomeMethod;
> begin
> ...
> UtilityProc(FSomeInstance);
> ...
> end;

Да еще и скомпилировать его:) Ну а кто мешал ему определить тогда метод-оболочку для вызова UtilityProc, тем самым дав четко понять, что это допустимо?
Но это все лирика. По-моему, мы уходим в нежелательную сторону от темы. Давай закончим.

to Набережных С. © (04.03.05 12:30) [52]:
>Автор UtilityProc не знал о существовании TSomeClass?
Давайте объясню ситуацию. Программист А написал TSomeClass, B - UtilityProc, C - TSomeOtherClass, D - TMyClass. Таким образом A не имел представления, что возникнет UtilityProc, а C и D уже имели реализованную процедуру.
Ситуацию можно упростить и испробовать на своей шкуре. Предположим, есть процедура, заполняющая TStrings какими-либо строками, имеющими значение и существующими только внутири какого-либо приложения. Мы хотим показывать эти значения, например, в ListBox и ComboBox.

Такая процедура не может быть сделана членом TStrings, т.к.:
1. класс уже определен
2. в момент определения класса TStrings не существовало приложения, где возникают значения

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

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

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

> C и D уже имели реализованную процедуру

"C" мог при необходимости определить метод-обертку, вызывающую UtilityProc? Мог. Я не говорю, что это наилучшее решение. Я говорю, что это возможно. И с TStrings опять не вполне корректно. У того же TListBox Items - свойство. И дает она доступ к содержимому внутреннего поля, но не к самому полю. И менять она позволяет состояние содержимого, но не само содержимое внутреннего поля. Похоже, мы о разных вещах говорим.

А теперь представим, что есть доступ к самому полю и пользователь класса меняет его содержимое. То есть просто записывает в него собственный объект вместо там имевшегося. И что? Один объект просто потерян, другой содержит собственные данные, но контейнер о сем факте не имеет никакой информации и отреагировать никак не может.

Адреса protected полей класса Найти похожие ветки