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

← →
DiamondShark © (2005-03-03 23:16) [40]

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

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

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

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

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

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

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

← →
Verg © (2005-03-03 23:26) [42]

> 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) - те же яйца, вид сбоку).
Одним словом - что, у кого заскорузло в голове, тот так и расценивает "адрес".

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

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

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

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

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

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

← →
Verg © (2005-03-03 23:52) [44]

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

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

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

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

← →
марсианин © (2005-03-04 00:43) [45]

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

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

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

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

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

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

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

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

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

← →
GuAV © (2005-03-04 00:56) [46]

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;

← →
Игорь Шевченко © (2005-03-04 01:01) [47]

Verg © (03.03.05 23:52) [44]

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

С уважением,

← →
SPeller © (2005-03-04 06:23) [48]

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

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

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

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

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

← →
SPeller © (2005-03-04 08:56) [50]

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

← →
vuk © (2005-03-04 11:16) [51]

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 полей класса Найти похожие ветки