private vs protected

← →
WebErr © (2004-04-21 16:24) [0]

Кто-нибудь скажет мне, зачем вообще нужна private-часть, когда всегда можно обойтись более гибкой protected?

← →
Dimka Maslov © (2004-04-21 16:26) [1]

прочитай про ООП основополагающие понятия - наследование, полиморфизм и инкапсуляция. Читать надо до просветления

← →
Игорь Шевченко © (2004-04-21 16:28) [2]

> зачем вообще нужна private-часть, когда всегда можно обойтись
> более гибкой protected

Для запрета видимости наследникам реализации класса-предка.

← →
Goida © (2004-04-21 16:33) [3]

Вообще, это всё для удобства программирования. Это актуально когда работаешь в команде или предпологается, что твой код будет смотреть кто-то другой...

← →
Digitman © (2004-04-21 16:36) [4]

> более гибкой protected

она для тебя "гибкая"

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

вот ты, к примеру, в опорном классе объявил некое защищенное поле и в конструкторе присвоил ему значение = 1 ... при этом подразумевая, что это есть некая "константа", равная присвоенному единожды значению на всем протяжении жизни объекта, при котором гарантируется работоспособность заложенной тобой логики ... далее ты отдал/продал/подарил свой DCU другому разработчику, никак не документировав упомянутое поле, но при этом разрешив доступ к нему в классах-наследниках ... тот самый другой разработчик, коль скоро ты разрешил доступ к полю, возьмет да изменит его значение по своему усмотрению (мало ли что ему в голову стукнет ! ты же это никак не ограничил) ... и что дальше ? а дальше ситуация у стороннего разработчика в его классе-наследнике выходит из под контроля, вплоть до полной неработоспособности объектов его класса !

← →
WebErr © (2004-04-21 16:37) [5]

> Dimka Maslov © (21.04.04 16:26) [1]

Я не хуже многих и многих здесь разбираюсь в ООП, а вот просветление светит не многим! :))))

> Игорь Шевченко © (21.04.04 16:28) [2]

Хоть один пример, когда нужно запретить наследнику пользоваться переменными предка будьте любезны! :))))

← →
Тимохов © (2004-04-21 16:39) [6]

> Я не хуже многих и многих здесь разбираюсь в ООП, а вот
> просветление светит не многим! :))))

не похоже (судя по вопросу).

> Хоть один пример, когда нужно запретить наследнику пользоваться
> переменными предка будьте любезны! :))))

еще лучше.

Вы чую очень хотите получить значок Л под номером АВ-000001?
:))) Оно надо ?

← →
Игорь Шевченко © (2004-04-21 16:45) [7]

> Я не хуже многих и многих здесь разбираюсь в ООП, а вот
> просветление светит не многим

Я извиняюсь, но у меня противоположное впечатление.

Впрочем, есть выход: на www.brainbench.com остался, вроде, бесплатный тест по ООП. Рекомендую пройти, чтобы укрепиться/усомниться в своих мыслях.

← →
WebErr © (2004-04-21 16:45) [8]

> Тимохов © (21.04.04 16:39) [6]

Мда!
Как минимум голословно!
Потомок тем и хорош, что получает от "отца" его свойства и методы, зачем же ему что-то запрещать???
Не знаю - не знаю!!! :))))

← →
WebErr © (2004-04-21 16:46) [9]

> Игорь Шевченко © (21.04.04 16:45) [7]

Всё-таки, хоть один пример!
Мне почему-то всегда очень жаль не давать наследнику что-то, что есть в предке...

← →
Romkin © (2004-04-21 16:49) [10]

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

← →
WebErr © (2004-04-21 16:51) [11]

> Romkin © (21.04.04 16:49) [10]

public не защищает от внешних модулей! :(

← →
Игорь Шевченко © (2004-04-21 16:53) [12]

> public не защищает от внешних модулей! :(

А protected защищает ? Бегом на brainbench

← →
Тимохов © (2004-04-21 16:54) [13]

> WebErr © (21.04.04 16:51) [11]
>
> > Romkin © (21.04.04 16:49) [10]
>
> public не защищает от внешних модулей! :(

впрочем как и protected.

Скажите вы когда были маленький, вам очень хотелось знать (вернее было нужно) как вас сделали? Вам что непременно было знать все физиологию? Сделали - и на том спасибо, а как - скрыто в объекте класса "пара папа+мама".

← →
WebErr © (2004-04-21 16:54) [14]

> WebErr © (21.04.04 16:37) [5]

Sorry если кого-то обидел, просто Object Pascal и С++ используют совсем не идентичный подход к ООП, а ООП я изучал именно на С++. !

← →
Palladin © (2004-04-21 16:57) [15]

А почему тебе не жаль давать в public все что есть вообще?

← →
Goida © (2004-04-21 16:58) [16]

А зачем нам вообще, в таком случае, что-то запрещать?

> WebErr

Скажи, зачем тебе protected?

← →
Anatoly Podgoretsky © (2004-04-21 16:58) [17]

Romkin © (21.04.04 16:49) [10]
public тоже нафиг не нужен, есть же более гибкий раздел published... Вот его только и надо пользовать!

← →
WebErr © (2004-04-21 16:58) [18]

> впрочем как и protected

Это только в Паскале! :))))
Всё - понял, почему вы так за него держитесь! :))))

← →
Игорь Шевченко © (2004-04-21 16:59) [19]

> Sorry если кого-то обидел, просто Object Pascal и С++ используют
> совсем не идентичный подход к ООП

Можно узнать, в чем разница ?

← →
Тимохов © (2004-04-21 16:59) [20]

> Можно узнать, в чем разница ?

во-во мне тоже интересно

← →
WebErr © (2004-04-21 17:00) [21]

> Скажите вы когда были маленький, вам очень хотелось знать
> (вернее было нужно) как вас сделали? Вам что непременно
> было знать все физиологию? Сделали - и на том спасибо, а
> как - скрыто в объекте класса "пара папа+мама".

А если нельзя а очень-очень хочется узнать?!

← →
Digitman © (2004-04-21 17:02) [22]

> WebErr © (21.04.04 16:54) [14]

да хоть на Си + сто плюсов !! суть ООП от этого нисколько не меняется

TBaseClass = class
private
F1: Integer;
protected
procedure SetField(Value: Integer);
end;

procedure TBaseClass.SetField(Value: Integer);
begin
if некоторое_условие then
F1 := Value;
...
end;

TDescClass = Class(TBaseClass)
..
procedure SomeProc;
end;

procedure TDescClass.SomeProc;
begin
F1 := хрен_знает_что; // а запросто ! ведь оно - защищенное !
Setfield(хрен_знает_что); // а вот тут далеко не запросто ! ибо классу TDescClass не дано ничего знать об некоторое_условие - не его это собачье дело !
end;

← →
WebErr © (2004-04-21 17:03) [23]

> Игорь Шевченко © (21.04.04 16:59) [19]

Учиться, учиться и ещё раз учиться!
Доступа нет в С++ к protected части ни у кого, кроме наследников и friends. Friends в свою очередь имеют доступ и к private, так нафиг тогда такой private?

← →
WebErr © (2004-04-21 17:03) [24]

В общем - я домой! ... Закладку поставлю... глядишь что-нибудь умное напишут (в конце-концов!)

← →
Тимохов © (2004-04-21 17:05) [25]

зачем вам умное - программистом вам не стать, т.к. программист домой в 17-00 не ходит - он ботает, не все конечно, некторые уже отботали, но вам точно это нужно.

:)))

← →
Goida © (2004-04-21 17:16) [26]

> WebErr

У тебя подход к этой проблеме не верный. Надеюсь, что дома ты откроешь книгу по ООП и посмотришь, зачем вообще были сделаны эти public, private и protected. Для программы они вообще не существуют. Friends - такой этот френдз. Поэтому и думать надо прежде чем что-то куда-то писать. Да и вообще нужно думать... А не просто так...

← →
Игорь Шевченко © (2004-04-21 17:16) [27]

> Учиться, учиться и ещё раз учиться!

Спасибо за рекомендацию, не премину воспользоваться.

Только вот один момент мне непонятен - чем реализация friends так уж сильно отличается от совместного использования классами, находящимися в одном модуле, внутренностей друг друга ? Еще учитывая, что в С++ модулей, как таковых, нету.

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

> WebErr

Вы хотели пример? Пожалуйста - совершенно стандартный пример.

type
TMyControl = class(TCustomControl)
private
FColor: TColor;
procedure SetColor(const Value: TColor);
public
constructor Create(AOwner: TComponent); override;
published
property Color: TColor
read FColor write SetColor default clWindow;
end;

constructor TMyControl.Create(AOwner: TComponent);
begin
inherited;
FColor := clWindow
end;

procedure TMyControl.SetColor(const Value: TColor);
begin
if FColor <> Value then
begin
FColor := Value;
Invalidate
end
end;

Теперь поразмыслите - можно ли (и стоит ли) выносить поле FColor и метод SetColor в любую другую секцию, кроме private?

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

← →
Гаврила (2004-04-21 17:29) [29]

> Anatoly Podgoretsky © (21.04.04 16:58) [17]
> Romkin © (21.04.04 16:49) [10]
> public тоже нафиг не нужен, есть же более гибкий раздел
> published... Вот его только и надо пользовать!

published тоже нафиг не нужен, есть более гибкий раздел - глобальные переменные

> Гаврила (21.04.04 17:29) [29]

предлагаю файл в "c:\" или в "с:\winnt"

>Тимохов © (21.04.04 17:31) [30]

предлагаю файл в "c:\" или в "с:\winnt"

Не, в фал не надо... лучше в реестре все держать или файлы в память проецировать...

Разница в парадигмах ООП Object Pascal и С++
1) паскаль использует ссылочную модель объектов
2) в паскале конструкторы и деструкторы автоматически не вызываются
3) Паскаль не поддерживает множественного наследования (оно возможно только через интерфейсы,
можно включением нужных классов в свой и выводом свойств на поверхность - но это не наследование)
4) в паскале нет понятия дружественных классов, но тоже самое получается когда классы расположены в одном модуле
5) в паскале нет отдельного понятия копирующего конструктора, используется метод Assign

Поправте если что забыл, но в остальном все одинаково за исключением синтаксиса языка

Очень хочется отца этой ветки переадресовать к книге Страуструпа С++ и книге М.Кенту Delphi 6 для проффесионалов (авторов с хорошим описанием ООП для паскаля много)

← →
Гаврила (2004-04-21 17:51) [33]

> ИЗ всего перечисленного значимым является только пункт 3

для вас? или для всех?

← →
Гаврила (2004-04-21 17:57) [35]

>>Тимохов © (21.04.04 17:52) [34]
Как разница в парадигмах ООП. Остальные отличия не существенны с точки зрения этой самой парадигмы

> Гаврила (21.04.04 17:57) [35]

согласен, но я бы еще отнес пункт про авт. вызов конструкторов.

> ) в паскале нет отдельного понятия копирующего конструктора,
> используется метод Assign

А в C++ есть ? Как элемент языка ? Не верю.

> Игорь Шевченко

Точно не известно, что имел автор этого поста ввиду (
> в паскале нет отдельного понятия копирующего конструктора,
>
> > используется метод Assign

). Но и там и там нужно писать отдельный метод. А как он называется, это дело 10е. В поём языке - копирксерокс.

> Юрий Зотов © (21.04.04 17:26)
С полем все понятно, а вот насчет метода - нет, к SetColor мы так и так имеем доступ через свойство Color, поэтому куда мы этот метод вынесем: в protected или даже в public принципиальной разницы ИМХО нет..(но саму идею private секции я не отрицаю ;-))

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

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