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 тоже нафиг не нужен, есть более гибкий раздел - глобальные переменные

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

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

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

← →
panov © (2004-04-21 17:38) [31]

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

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

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

← →
vl_chel © (2004-04-21 17:41) [32]

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

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

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

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

>>vl_chel © (21.04.04 17:41) [32]

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

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

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

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

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

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

← →
Тимохов © (2004-04-21 18:01) [36]

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

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

← →
Игорь Шевченко © (2004-04-21 18:02) [37]

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

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

← →
Goida © (2004-04-21 18:32) [38]

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

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

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

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

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

← →
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 видимость полей и методов иногда необоснованно заужена.

← →
Kto © (2004-04-23 19:59) [69]

Я полагаю, что всё-таки авторы как-то это обосновали.
Да и не думаю, что они предсмотрели все варианты использования их кода. Там иногда такие перлы попадаются... :)
Н-р:
В 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);

← →
WebErr © (2004-04-26 16:13) [70]

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

← →
WebErr © (2004-04-26 16:15) [71]

← →
WebErr © (2004-04-26 16:29) [72]

Ну вот, например:
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, а я потом скажу, где Вы все ошиблись! :))))
(Заодно тест на ООП для самых "одарённых"!)

← →
WebErr © (2004-04-26 16:37) [73]

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

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

← →
panov © (2004-04-26 16:37) [74]

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

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

← →
WebErr © (2004-04-26 16:41) [75]

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

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

← →
Digitman © (2004-04-26 16:41) [76]

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

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

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

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

← →
WebErr © (2004-04-26 16:45) [77]

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

← →
panov © (2004-04-26 16:50) [78]

Код этот весь неправильный.
Вместо этого -
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.

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

← →
WebErr © (2004-04-26 16:55) [79]

Это мой собственный код! :))))
Могу объяснить каждую запятушку, правда восстановлен он по памяти, поэтому наверное не компилится!
Фишка в том, что вместо <а здесь на любителя>, нужно что-то ставить.
В Паскале отсутствует столь нужный мне 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;
...

← →
WebErr © (2004-04-26 17:07) [81]

> Digitman © (21.04.04 17:02) [22]

Гений, наверное! :))))

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

В паскале нет inline, template, operator, ... короче скрестили слона с носорогом - это вообще разные по своей сути языки!!! Паскаль изначально был рассчитан как более высокоуровневый нежели С, как и С++, а вот С++ создавался специально для ООП - вся структура С++ говорит - здесь живут классы! А вот переделать Паскаль в Обжект Паскаль было на порядок сложнее, вспомнить хотя бы tp7.0 - все вспомнили? Delphi чуть поправило дело, но по сути - это модульный, а не Объектно ориентированный язык, это как Perl и PHP, если кто знает такие языки и то, как там всё организованно! ;)

← →
Digitman © (2004-04-26 17:26) [82]

> WebErr © (26.04.04 17:07) [81]

> Гений, наверное! :))))

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

← →
panov © (2004-04-26 17:28) [83]

Пост panov © (26.04.04 16:37) [74] именно в тему, так как непонятно, что за код и зачем он нужен, откуда он вообще вытащен и для чего он предназначен.

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

← →
Anatoly Podgoretsky © (2004-04-26 17:34) [84]

При том не важно что писать, что напишешь то и будет неправильным. Образ гозера вы можете выбрать сами.

← →
WebErr © (2004-04-26 17:43) [85]

> panov © (26.04.04 17:28) [83]

Книжки вы тоже так внимательно читаете? 8)

> Digitman © (26.04.04 17:26) [82]

:)))) - это смачная, кривая улыбка во весь рот, а не тупое алкоголическое ржание! :))))

← →
Digitman © (2004-04-26 17:44) [86]

> WebErr © (26.04.04 17:07) [81]

изрядно отдает банальной демагогией

← →
WebErr © (2004-04-26 17:47) [87]

> Digitman © (26.04.04 17:44) [86]

А поконкретнее критику будьте любезны! :))))

← →
Digitman © (2004-04-26 17:53) [88]

демагогия несовместима с критикой, ибо она демагогия и не более того
а свое imho по сабжу вопроса и ржанию твоему в целом я тебе уже сказал

← →
WebErr © (2004-04-26 18:02) [89]

> Digitman © (26.04.04 17:53) [88]

Вот это как раз и есть демагогия - по определению она появляется, когда других аргументов больше нет! :))))

← →
Digitman © (2004-04-26 18:05) [90]

тебе видней... продолжай в том же духе, авось тебе полегчает

← →
WebErr © (2004-04-26 18:15) [91]

> Digitman © (26.04.04 18:05) [90]

Это не болезнь - это собрание информации для создания нового по своей концепции языка с более совершенной моделью ООП.

← →
Anatoly Podgoretsky © (2004-04-26 18:48) [92]

Ну тебе надо кооперироваться с Дмитрием

← →
WebErr © (2004-04-26 18:53) [93]

> Anatoly Podgoretsky © (26.04.04 18:48) [92]

Кто это?

← →
vuk © (2004-04-26 19:12) [94]

to WebErr © (26.04.04 17:07) [81]:

Ой, блин, держите меня..... :o)))

>В паскале нет inline, template, operator
inline - не знаю, нужен ли, template - будет, operator уже считайте, что есть. :o)

>Паскаль изначально был рассчитан как более высокоуровневый
>нежели С,
Паскаль старше, чем C. И уж тем более C++.

>как и С++, а вот С++ создавался специально для ООП - вся
>структура С++ говорит - здесь живут классы!
Видели бы Вы его ранние версии.

>но по сути - это модульный, а не Объектно ориентированный язык,
1. Одно другому не противоречит.
2. Без модульности, которой, кстати, в C/C++ нет, там пришлось изобретать такие вещи, как пространства имен, которые в модульных языках нафиг не нужны.
3. Что C++, что Delphi - это, по сути своей, не объектные языки, а процедурные с объектными расширениями.

← →
Игорь Шевченко © (2004-04-26 22:19) [95]

На APL надо программы писать. В крайнем случае, на структурном RPG (для справки - это не Role Playing Game, а Report (слово забыл) Generator, был давным давно на IBM-овских машинах, уже тогда на него программисты плевались).

WebErr © (26.04.04 18:15)

Тебе - прямая дорога Гради Буча читать. Наизусть.

← →
WebErr © (2004-04-27 17:26) [96]

> vuk © (26.04.04 19:12) [94]
> inline - не знаю, нужен ли, template - будет, operator уже
> считайте, что есть. :o)

Вот когда будет, тогда и поговорим! 8)

> Паскаль старше, чем C. И уж тем более C++.

Верно, но до появления Турбо Паскаля его и за язык-то не считали! Все предпочитали грёбаный Бейсик! Судите сами об уровне этого языка в те далёкие от моего рождения времена...

> Видели бы Вы его ранние версии

Видел, и даже книжку старую по нему читал - прикол, даже нету ничего того, чем он выгодно выделяется сегодня (кроме скорости) не удивительно, что тогда многие предпочитали язык С, а не С++. Про template тогда вообще и не думали! :))))

> 1. Одно другому не противоречит.
> 2. Без модульности, которой, кстати, в C/C++ нет, там пришлось
> изобретать такие вещи, как пространства имен, которые в
> модульных языках нафиг не нужны.
> 3. Что C++, что Delphi - это, по сути своей, не объектные
> языки, а процедурные с объектными расширениями.

В общем-то согласен... молчу-молчу...

> Игорь Шевченко © (26.04.04 22:19) [95]

Из всего Вами-всеми-уважаемым-мастером-высшей-категории-достоинства-чьи-признаны-на-международном(межпланетном)-уровне я заключил следующее:
1) сказать что-либо путное Вы не можете ну никак!
2) об остальных языках Вы только наслышаны - отсюда ваша компактность (замкнутость и ограниченность)...
3) настоящий Мастер всегда вежлив => Вы не Мастер.
4) единственное более-менее ценное, что Вы мне ответили - это коротенький 1-й пост, остальное - хлам!
....................................................
To all
Я люблю паскаль, так как он стоял у истоков моего развития, поэтому всё, что я пишу о нём, я пишу либо с лёгкой иронией, либо с теплом в сердце (sorry за сентименталити).
with best regards, Weber

← →
WebErr © (2004-04-27 17:27) [97]

Удалено модератором
Примечание: Дубль

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

> 1) сказать что-либо путное Вы не можете ну никак!
> 2) об остальных языках Вы только наслышаны - отсюда ваша
> компактность (замкнутость и ограниченность)...
> 3) настоящий Мастер всегда вежлив => Вы не Мастер.
> 4) единственное более-менее ценное, что Вы мне ответили
> - это коротенький 1-й пост, остальное - хлам!

Да хоть горшком назови :)

← →
VMcL © (2004-04-27 17:35) [99]

>>WebErr © (27.04.04 17:27) [97]

Слава http://www.delphimaster.ru/cgi-bin/anketa.pl?id=1050566399 не даёт покоя?

← →
Digitman © (2004-04-27 17:36) [100]

> WebErr © (27.04.04 17:26) [96]

то что ты клоун - это было понятно изначально

так что совет тебе был дан верный - кооперируйся с Дмиртийолегычем из "Потрепаться": в оном тот уже поднаторел, вам будет о чем обменяться мнениями

← →
nikkie © (2004-04-27 19:07) [101]

В крайнем случае, на структурном RPG (для справки - это не Role Playing Game, а Report (слово забыл) Generator, был давным давно на IBM-овских машинах, уже тогда на него программисты плевались).
Report Program Generator, как не сложно догадаться. :)

лет 7 назад, кстати, мне пришлось чуть-чуть на нем писать. правда не знаю, стоит ли его называть структурным. жестко позиционный язык, но вроде совсем не структурный.

забавно, что IBM его придумала для того, чтобы программированием могли заниматься непрограммисты. этакий Visual Basic 60-х. :))

однозначно - набор кодеров в паре с дмитрием - он будет супер-пупер комментатор писать, ты - объектный язык.

nikkie © (27.04.04 19:07)

Название "Структурный RPG" взято из подписей к саге о Crunchy Гая Стила.
Суть саги в том, что рекламировали Water Powered Computer, операционная система которого была написана на Структурном RPG, по тем временам (70-ые года) эту шутку могло оценить большое количество программистов. Я сам (свят-свят-свят) сталкивался только с документацией по RPG (не структурному) во времена работы на ЕС-10хх.

Народ, мы так к ничему и не пришли. Я наблюдал со стороны и пришел к мнению, что никто не пытался поставить точки над i. Нужно просто урезонить этого ВБР и дать ему прочитать книгу Джесса Либерти. И он сам станет на нашу сторону. Вот и всё.

А теперь обращаюсь к ВБР:
Ты вотт здесь всех осмеиваешь, а сам то ничего путного тоже несказал. Это глупая позиция, которую ты занимаешь. Что-то типа такой: "Я здесь самый умный, попробуйте доказать обратное". Кому нужно это доказывать? Придет время и ты поймешь кто ты есть. А в данном вопросе ты не прав.

> он будет супер-пупер комментатор писать, ты - объектный
> язык.

Этот будет язык писать, а Дмитрий к нему комментатор-ПуперСхемопостроитель, без которого понять язык будет невозможно.

То, что Дмитрий О. тоже из Ярославля вас всех не смущает? 8)

> Digitman © (27.04.04 17:36) [100]

Мда - одни эмоции - 0 ценной инфы - вот, кто здесь КПД=0.

> Goida © (28.04.04 15:00) [104]

Единственный ценный пост. Хорошо, почитаю я эту книгу, если напишите как она называется и про что она.

> SPeller © (28.04.04 15:57) [105]

Смехописатель я и сам написать могу! :))))

> Игорь Шевченко © (27.04.04 17:35) [98]

Ладно, извините, погорячился! 8) LMD ваше меня из себя вывело...

> WebErr

Сылка должна рассказать немного:
http://www.samspublishing.com/title/067232072X
Главное, посмотри кто автор.
По теме: он не утверждает, что обязательно нужно использовать какие-то из слов: private, protected или public... Это дело рук программиста. Но, естественно, и решение всех проблем, связанных с неуместным использованием этих слов, так же дело рук самого программиста.
О книге: хорошая, мне очень понравилась, все понятно написано и не занудно. В свое время мне очень помогала.

> WebErr

Кстати, попробуй обсудить этот вопрос на сайте RSDN.RU

2 WebErr
Лично я в твоих постах чувствую логику (хотя далеко не все прочитал и понял). Насчет нового языка - пиши мне на мыло - поговорим.
(igor_orobchuk at yahoo dot co dot uk).

> Goida © (29.04.04 09:46) [107]

Был на ссылке:
http://www.samspublishing.com/title/067232072X
ничего, кроме книг по С++, типа, изучите за 21 день...
Я его за 2 месяца еле изучил и даже до сих пор продолжаю изучать на пару с Делфи...
Всё равно спасибо.

> Goida © (29.04.04 10:30) [108]

Разница-то какая?

> Igorek © (29.04.04 10:58) [109]

Хорошо - напиши письмо на
xa.kep@mail.ru
Я в своих постах тоже логику чувствую... удивительно, правда? 8)

Кстати, всё равно я - прав!
Секция private должна исчезнуть под влиянием protected.

> Секция private должна исчезнуть под влиянием protected.

Карфаген должен быть разрушен.

Удалено модератором
Примечание: Offtopic

> WebErr © (29.04.04 15:51) [111]
> Кстати, всё равно я - прав!

Более, чем прав. Лев!

См. постинги [1], [2] и [7] в ветке:
http://delphi84.valuehost.ru/cgi-bin/forum.pl?id=1083158142&n=0

Ни на какие мысли не наводит? Или еще примеры привести?

> WebErr

Глупенький. Книга названа так образно. Там 21 часть. А объем в 600 стр. или около того. Ты хоть посмотрел кем автор является.
А на сайт RSDN сослал, чтобы ты поговорил с теми, кто работает на C++. Для них очевидней зачем нужен private. Тем более ты там будешь обсуждать так горячо любимый тобой C.
На счет создания своего языка. Это нужно, если будет лучше. Подумай реально, тех сил, которыми ты сейчас обладает хватит, чтобы сделать это?

> Как это там по латыни? ...
Las Carphagenius Must be Destroyed :)
Шутка. Я в латыни не силен, это к доктору или к ботаникам :)

> Секция private должна исчезнуть под влиянием protected.
Вместе с последним ламером, который ее использует :)
Ведь заметьте, использование private - дело добровольное, синтаксис языка не заставляет что-то туда писать.
Оно, конечно, иногда бесит, когда private используют (с точки зрения юзера) необоснованно. Но даже если какой-то классописатель все запихал туда, закрыв вполне очевидные возможности расширения - так это он дурак, а не авторы языка.

Сделаю очередную попытку привести пример, где private нужно.
TWBEClass = class(TSomeClass) protected FA: integer; public property A: integer read FA write FA; end; Потом (через месяц) Вы поняли, что допустили ошибку - класс должнен быть таким: TWBEClass = class(TSomeClass) protected FA: integer; procedure SetA(Value: integer); public property A: integer read FA write SetA; end; procedure TWBEClass.SetA(Value: integer); begin if DayOfWeek(now) = 4 then raise Exception.Create("По четвергам св-во А присваивать запрещено :)"); FA := Value; end;

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

> Petr V. Abramov

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

Carthago delena est :)

> TWBEClass = class(TSomeClass)
> protected
> FA: integer;
> public
> property A: integer read FA write FA;
> end;

TNewWBEClass = class(TWBEClass)
protected
FA: Integer;
procedure SetA(Value: Integer);
public
property A: Integer read FA write SetA;
end;
?
Что-то я совсем не понял суть примера?
И где здесь запихнуть хоть какой-то private?

Удалено модератором
Примечание: Offtopic

> WebErr

> Что-то я совсем не понял суть примера?

Представь, ты создал этот класс (вариант 1) и наделал кучу потомков. Потом вдруг решил: "Не нуна "procedure SetA(Value: Integer); пользоваться...". Поменял. Теперь у тебя вариант 2. И все работает. Ты счастлив? Если да, тогда бери Джесса Либерти и читай его, а потом продолжай разговаривать о том нужен ли private.
Но если ты не понимаешь, то слушай. У тебя везде было присваивание к FA. Поэтому новый вариант класса утебя не будет работать так, как ты хочешь. Для того, чтобы работал SetA, нужно FA поместить в private...
Уф! Ты ведь должен знать это ?)

TNewWBEClass2 = class(TNewWBEClass)
end;

FA := 1;
И что бы ты не творил в дальнейшем со своим SetA ты приплыл парень, пока не переместишь FA в private

> Для того, чтобы работал SetA, нужно FA поместить в private...
Для того, чтобы всегда работал именно SetA

>Секция private должна исчезнуть под влиянием protected.
- дарагой товарисч, а вы никогда не слышали - инкапсуляция, полиморфизм, скрытие/защита реализации?
А может слышали про контроль ошибок на этапе компиляции?

Хм... ВБР тихо ушел...

Нет, вы не поняли меня, допустим я создал
TBase = class
private
FA: Integer;
procedure SetA(Value: Integer);
public
property A: Integer read FA write SetA;
end;

А потом захотел как-то работать именно с FA а не с A в одном из потомков - единственный выход:
FA - в protected.

И всё!
Плакала ваша теория!

> han_malign © (29.04.04 18:31) [126]

Наследование забыл! Гений! :))))
Без сопливых знаю! :)
Знаком я с ООП! Оч хор значом! Заколебало меня уже отвечать на такие выпады, просто меня бесит private секция!!!

Кстатти, [72] всё ещё ждёт разъяснения:
это предок класса TDynMatrix.
С произвольным буффером.
TDynMatrix порождает T3DGrid, T24BitRaster и TZBuffer.
С любым вариантом private на данном примере это будет завал.
Так как все переменные мне нужны в одном из потомков!
with best wishes... ваш ВБР! :)

> Anatoly Podgoretsky © (29.04.04 17:43) [124]

Может я хочу работать с FA также и в некой другой функции класса наследника!

ХОчешь работать, работай, но карты не передергивай.

> WebErr © (30.04.04 18:40) [130]
> Может я хочу
А вот Ваша задача как проектировщика классов - спроектировать так, чтобы хотение не возникало. За ненадобностью. И отсутствие возможности работать с FA, даже при хотении, не лишало наследников гибкости.
А вообще - пишите все в public, если так хочется. Только когда Вас заставят разгребать последствия, не кричите, что у программистов жизнь хреновая.
А если пишете тихо сам с собой, ну пихайте все в public.
А вот попадете в перспективную команду Дмитрия О., так он Вас как собаку из пневматики ;)

> просто меня бесит
программируйте в наморднике :)

Ok, Вы все вместе дружно кто как и кое-как защитили-таки private секцию от поругания! :))))
Вопросов больше не имею... более того, скажу Вам по секрету, я проникся нежными чувствами к данной секции, но использовать её больше чем нужно я просто из рациональности склада моего мозгу не буду! ;)
Спасибо всем, кто принял участие в обсуждении! :)
До нового сабжа! :)

Всё-таки все настолько привыкли к private секции, что даже не все знают, зачем она конкретно нужна или знают, но объяснить не могут! ;)

> WebErr © (05.05.04 14:44) [134]
> Всё-таки все настолько привыкли к private секции, что даже
> не все знают, зачем она конкретно нужна или знают, но объяснить
> не могут! ;)

Ну, а для чего она нужна? Конкретно?

> Ну, а для чего она нужна? Конкретно?

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

> MalkoLinge

Я это и без тебя знаю :) Я у WebErr спрашиваю, только он мне не ответит уже... наверно...

Я это ему тоже адресовал :)

> Goida © (05.05.04 16:52) [140]

Извращенцы, полюбившие защищать данные от левых классов и посредственных пользователей, (которые просто сделали вид, что защитились!) любят теперь "защищаться" и от собратьев по программированию, которые настолько полюбили ООП, что уже даже создают потомков от наилюбимейших Ваших Классов - вот от "защиты" от такого "беспредела" и нужна private фикция. :)

Удалено модератором
Примечание: Offtopic

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