private vs protected

← →
Palladin © (2004-04-21 19:51) [40]

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

← →
Юрий Зотов © (2004-04-21 20:04) [41]

> Jack128 © (21.04.04 19:29) [39]

> куда мы этот метод вынесем: в protected или даже в public
> принципиальной разницы ИМХО нет..(

Вс же есть. Приватный метод не может быть переписан в наследнике - тем самым мы защищаем свой компонент от кривых рук его юзеров.

← →
Jack128 © (2004-04-21 20:18) [42]

> Вс же есть. Приватный метод не может быть переписан в наследнике
> - тем самым мы защищаем свой компонент от кривых рук его
> юзеров.
?? Что изменит если в наследнике кто то перепишет SetChild??? Новый setColor будет вызываться только в коде наследнике и ничуть не повлияет на поведение предка

type
TTest = class
private
FColor: TColor;
protected
procedure SetColor(const Value: TColor);
public
property Color: TColor read FColor write SetColor;
end;

TChildTest = class(TTest)
protected
procedure SetColor(const Value: TColor);
end;

{ TTest }

procedure TTest.SetColor(const Value: TColor);
begin
FColor := Value;
end;

{ TChildTest }

procedure TChildTest.SetColor(const Value: TColor);
begin
inherited SetColor(Value);
ShowMessage("SetColor in Child");
end;

procedure TForm1.Button1Click(Sender: TObject);
var
t: TChildTest;
begin
t := TChildTest.Create;
try
t.Color := clRed; // никакого мессаджа не будет..
finally
t.Free;
end;
end;

Я не хочу сказать что помещать методы в private не нужно, но то что статические мододы доступа обычно помещаются в private секцию ИМХО никакого отнашения к ООП не имеет, а объесняется ли нежеланием захламлять public/published секцию...

← →
Anatoly Podgoretsky © (2004-04-21 20:37) [43]

Нет для того чтобы защищить реализацию этого метода, обход которого может быть чреват. Так что прямое отношение к ООП, а захламление все рано происходит, строчка с объявление, что в риват, что в протектед таже самая.

← →
Jack128 © (2004-04-21 20:46) [44]

> обход которого может быть чреват.
каким образом можно обойти TTest.SetColor ?? При обрашении к свойству Color этого метола гарантирован, что бы там наследники не намудрили..

> захламление все рано происходит, строчка с объявление, что
> в риват, что в протектед таже самая.
я имел ввиду захламление для тех кто использует этот класс, как предка

← →
Jack128 © (2004-04-21 20:52) [45]

> При обрашении к свойству Color этого метола гарантирован
читать как:
При обрашении к свойству Color вызов этого метода гарантирован

← →
Юрий Зотов © (2004-04-21 21:09) [46]

> Jack128 © (21.04.04 20:18) [42]

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

← →
Андрей Сенченко © (2004-04-21 21:13) [47]

Юрий Зотов © (21.04.04 21:09) [46]

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

Я без поддёвок - действительно интересно

← →
Anatoly Podgoretsky © (2004-04-21 21:21) [48]

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

← →
Андрей Сенченко © (2004-04-21 21:25) [49]

Anatoly Podgoretsky © (21.04.04 21:21) [48]

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

← →
Jack128 © (2004-04-21 21:29) [50]

> Адреса подменю, код в памяти скопирую
Типа в хакеры записались ;-) Я думаю если вы захотите, то и в прайвит методе адрес подмените

← →
Юрий Зотов © (2004-04-21 21:44) [51]

> Jack128 © (21.04.04 20:18) [42]

Кстати - конкретно для Вашего примера даже никаких хакерских штучек не требуется - надо просто добавить в объявление TChildTest всего одну строчку:

TChildTest = class(TTest)
protected
procedure SetColor(const Value: TColor);
public
property Color: TColor read FColor write SetColor;
end;

Вот и весь "взлом".

> Андрей Сенченко © (21.04.04 21:13) [47]

Protected - это ерунда, в потомке класса могу делать, что хочу. Хуже, когда метод статический.

А примеров - навскидку, могу привести два (хотя подобных случаев было куда больше). Оба примера реальные.

1. Свойство Application.MainForm - только для чтения. Как быть, если каждому юзеру требуется иметь свою главную форму? Точнее говоря, класс формы у всех один, а вот ресурсы - разные (хранятся отдельно от EXE и заливаются снаружи).

2. Хочу иметь TListView со своими Items и Columns. Написать наследников TListItems и TListColumns - не вопрос. Заменить стандартные Items своими - тоже не вопрос, достаточно заместить метод CreateListItems. А вот для Columns аналогичного механизма почему-то не предусмотрено.

← →
Jack128 © (2004-04-21 22:08) [52]

> Юрий Зотов © (21.04.04 21:44)
А что, от такого "взлома" перенос SetColor в private спасет? ;-)

← →
Юрий Зотов © (2004-04-21 22:46) [53]

> Jack128 © (21.04.04 22:08) [52]

Неа, не спасет. И вот это, IMHO, как раз и есть одна из вещей, которые оставляют желать лучшего в Delphi-модели ООП.

← →
WebErr © (2004-04-22 18:28) [54]

Мда, единственно ценное из вышесказанного - это то, что практически все программисты боятся некоего абстрактного "юзверя". :))))

← →
Игорь Шевченко © (2004-04-23 11:23) [55]

WebErr © (22.04.04 18:28)

> единственно ценное из вышесказанного

У нас разная система ценностей.

---
LMD

← →
Anatoly Podgoretsky © (2004-04-23 11:24) [56]

WebErr © (22.04.04 18:28) [54]
Не все боятся, некоторые создают экземляры базового юзера

← →
Goida © (2004-04-23 11:31) [57]

> WebErr

Ты мнишь себя гением... :-.

← →
Матлабист (2004-04-23 12:29) [58]

> protected тоже нафиг не нужен, есть же более гибкий раздел
> public... Вот его только и надо пользовать!

И вообще, нафиг эту модульнсть --- гибче писать все в одном файле ;)

← →
Goida © (2004-04-23 13:06) [59]

да лучше вообще не писать, пусть другие парются...

← →
Locker (2004-04-23 13:36) [60]

Из разговора в институтской курилке:
- protected лучше, чем private!
- нет, private лучше!
- нет, protected!
- ну и чем, чем лучше?
- чем private!

← →
vl_chel © (2004-04-23 14:03) [61]

>> Гаврила (21.04.04 17:51) [33]
полностью согласен
>>Goida © (21.04.04 18:32) [38]
не буду спорить ООП учил по книге Страуструпа очень давно - тогда паскаль еще не был объектным мог запамятовать

Я имел в виду именно парадигму ООП, а не синтаксическую реализацию кода

Хочу заметить что ООП - идеология составления текстов программ, а не способа их выполнения на ЭВМ.

← →
Nous Mellon © (2004-04-23 14:29) [62]

Чего вы взъелись то? Парень проходит кастинг на роль Дмитрия О.
Видимо скоро повится AvtoObjeсtReader какой-нибудь.

← →
evvcom © (2004-04-23 14:35) [63]

Жестокий спор! Как бы мы не защищались от хакера - не спасет ничего, если талантливому и нефиг делать хакеру взбредет в голову поломать нашу прогу.

Даже объявление
private
FMainForm: TForm;
public
property MainForm: TForm read FMainForm;
тоже не спасает нас на 100%. Простейшая конструкция:

type
PForm = ^TForm;
...
PForm(@Application.MainForm)^ := MyForm;

влегкую подменяет приватную переменную.

Я бы здесь отметил, что правильное использование private, protected и т.д. является "хорошим тоном" в программировании. private предостерегает юзверя, что сюда не надо бы лезть, но коль уж тебе так неймется, то все это на твой страх и риск. Т.е. если правильно используешь мой компонент, то я отвечу за него (на вопросы и т.д.), в противном случае - пошел на фиг.

Горячая беседа получилась...

← →
Anatoly Podgoretsky © (2004-04-23 14:45) [64]

Речь то не о защите от хакера, ломать нечего, когда есть исходники, речь про то зачем и как использовать.

← →
evvcom © (2004-04-23 14:54) [65]

> речь про то зачем и как использовать

это изначальный вопрос, но потом его настолько развили, что речь уже пошла и про "защиту от хакера". И даже тот факт, что у меня есть исходники стандартных для Delphi классов, мне помогает лишь изучать исходный код, но исправить его я могу далеко не всегда.

← →
Anatoly Podgoretsky © (2004-04-23 15:03) [66]

evvcom © (23.04.04 14:54) [65]
Скажу на это одной популярной фразой

Не трогай генофонд зараза, а то пожелеешь.

← →
evvcom © (2004-04-23 15:19) [67]

> Не трогай генофонд зараза, а то пожелеешь.

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

Поэтому для меня эта тема закрыта...

← →
Sha © (2004-04-23 16:36) [68]

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

Я полагаю, что всё-таки авторы как-то это обосновали.
Да и не думаю, что они предсмотрели все варианты использования их кода. Там иногда такие перлы попадаются... :)
Н-р:
В TCustomComboBox"е

if DroppedDown then
DrawFrameControl(C.Handle, R, DFC_SCROLL, DFCS_FLAT or DFCS_SCROLLCOMBOBOX)
else
DrawFrameControl(C.Handle, R, DFC_SCROLL, DFCS_FLAT or DFCS_SCROLLCOMBOBOX);

В общем раскрываю карты...
Весь сыр-бор я затеял из-за того, что защищать данные надо от юзера так, чтобы программер мог до них добраться - в этом случае мне совсем не нравится то, что от меня что-то где-то прячут и уж совсем необосновано "LMD" (И.Ш.M.D. (с))! Во времена Турбо Паскаля 7.0 обходились просто двумя секциями private и public - protected появилась после, дополняя всё это "хозяйство", а уж published вообще никакого отношения к ООП не имеет, так как это - фикция, придуманная Борландовцами.
Мне кажется, и это - лично моё мнение, что хватило бы и 2-х секций - одна для программеров и "имподобных" - protected - гибкая, защищённая секция, а другая - public, для тех, кто просто использует возможности "чего-то-вами-созданного".
P.S. Примеры, приведённые в этой ветке, считаю неубедительными, так как невозможно программеру доказать как и зачем ему защищать данные и методы от программера.

Ну вот, например:
TDynArray = class protected FBytes: Word; FCount: Longword; FSize: Longword; FBuffer: Pointer; procedure ResetParams; virtual; function GetPElem(AIndex: Longword): Pointer; public constructor Create(ABytes: Word); virtual; function SetCount(ACount: Longword): Boolean; virtual; property Bytes: Word read FBytes; property Count: Longword read FCount; property Size: Longword read FSize; property Buffer: Pointer read FBuffer; property PElem[AIndex: Longword]: Pointer read GetPElem; default; end;
Скажите, что я должен занести в private, а я потом скажу, где Вы все ошиблись! :))))
(Заодно тест на ООП для самых "одарённых"!)

> evvcom © (23.04.04 14:35) [63]
> Я бы здесь отметил, что правильное использование private,
> protected и т.д. является "хорошим тоном" в программировании.
> private предостерегает юзверя, что сюда не надо бы лезть,
> но коль уж тебе так неймется, то все это на твой страх и
> риск. Т.е. если правильно используешь мой компонент, то
> я отвечу за него (на вопросы и т.д.), в противном случае
> - пошел на фиг.

Чем protected хуже? :))))

Из серии "Иди туда, не знаю куда, принеси то, не знаю что..."

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

> panov © (26.04.04 16:37) [74]

Из серии "... ну и пусть себе плывёт - нам не нужен пенопласт ..." - не в тему! :))))

> WebErr © (26.04.04 16:29) [72]

слушай-ка , "одаренный", ты упрям как мул !

"юзеру" передаются DCU и BPL
"программеру" передаются кр.того исходники

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

Первый пошёл! :))))

Код этот весь неправильный.
Вместо этого -
TDynArray = class protected FBytes: Word; FCount: Longword; FSize: Longword; FBuffer: Pointer; procedure ResetParams; virtual; function GetPElem(AIndex: Longword): Pointer; public constructor Create(ABytes: Word); virtual; function SetCount(ACount: Longword): Boolean; virtual; property Bytes: Word read FBytes; property Count: Longword read FCount; property Size: Longword read FSize; property Buffer: Pointer read FBuffer; property PElem[AIndex: Longword]: Pointer read GetPElem; default; end;

- пишем

var
DynArray: array of <а здесь на любителя>;

PS.

В следующий раз не надо копировать пустой код из исходников компонент.

Это мой собственный код! :))))
Могу объяснить каждую запятушку, правда восстановлен он по памяти, поэтому наверное не компилится!
Фишка в том, что вместо <а здесь на любителя>, нужно что-то ставить.
В Паскале отсутствует столь нужный мне template <class T>
Полный код не привожу, т.к. вы сразу догадаетесь, на чём я Вас хочу поймать...
Удачи! :))))

← →
Locker (2004-04-26 16:58) [80]

WebErr © (26.04.04 16:29) [72]

Особо хорош момент:
...
function SetCount(ACount: Longword): Boolean; virtual;
...
property Count: Longword read FCount;
...

private vs protected Найти похожие ветки