Есть ли в Object Pascal friend, как С++

← →
Tihas © (2002-10-11 01:30) [0]

Есть ли в Object Pascal friend, как С++ или что-то подобное.

← →
Suntechnic © (2002-10-11 01:45) [1]

friend-ы в С++ подрывают основы инкапсуляции и их использование крайне не рекомендовано (есть только несколько исключений таких как переопределение операторов не членов класса). Разве Вас этому не учили? Не переносите дурную технику в Delphi.

← →
^Sanya © (2002-10-11 01:52) [2]

Полностью согласен с
> Suntechnic © (11.10.02 01:45)

← →
Tihas © (2002-10-11 01:56) [3]

Вопрос стоял наверное подругом, всё таки есть или нет?
Заранее спасибо.

← →
Suntechnic © (2002-10-11 04:50) [4]

>Tihas © (11.10.02 01:56)
...всё таки есть или нет?

Всё-таки наверное нет :). Но как говаривал Козьма Прутков "Зри в корень", поэтому тебе и попытались объяснить почему нет.

← →
MBo © (2002-10-11 06:29) [5]

Классы, описанные в одном модуле.

← →
evgeg © (2002-10-11 08:58) [6]

Все классы и функции, описанные в одном модуле имеют доступ ко всем членам друг друга.

← →
Толик © (2002-10-11 10:05) [7]

to Suntechnic © (11.10.02 01:45)
Интересно, а то что все классы в одном модуле видят все private-переменные других классов этого модуля - это что, не "подрыв основ"??? В С++ хотя бы сам класс разрешает другим классам/функциям доступ к своему нутру, а в Делфях это происходит не зависимо от того, желает этого разработчик или нет.
Так что Делфя в этом случае ведйт себя более грубо :)

← →
Dimka Maslov © (2002-10-11 10:15) [8]

>Toлик
Если разработчик пожелает, он разнесёт классы в разные модули. В одном же модуле обычно размещают классы, имеющие одно общее предназначение, так-что доступ к закрытым членам просто необходим.

← →
still © (2002-10-11 10:24) [9]

> Dimka Maslov © (11.10.02 10:15)
> >Toлик
> так-что доступ к закрытым членам просто
> необходим.

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

← →
Anatoly Podgoretsky © (2002-10-11 10:34) [10]

Это появилось еще до того как появились методы и свойства, и да до объектов, тогда это была насущная необходимость, теперь же это больше во вред. Но и использование это в public не есть хорошо, открывает за пределы модуля.

← →
still © (2002-10-11 10:41) [11]

>2 Anatoly Podgoretsky ©

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

← →
Толик © (2002-10-11 10:43) [12]

to Dimka Maslov © (11.10.02 10:15)
Выкрутится можно всегда (ну или почти всегда), но сколько же можно выкручиваться?
Впрочем, это уже вопрос вкуса. Лично мне кажется, что организация доступа через friend более грамотная, кто-то может с этим поспорить. Суть не в этом. Изначально вопрос стоял так: "есть ли аналог friend в Делфях?" и ответ на него был дан МВо ещё четыре часа назад.
Как говорится: "если программист в 9 утра уже на работе, значит он ЕЩЁ на работе" :)))

← →
Suntechnic © (2002-10-11 15:42) [13]

Флеймить так флеймить :)
Я бы сказал что наличие классов в одном модуле это не есть полный аналог friend. Потому как friend-ами в С++ могут быть как классы так и отдельные ф-ции, чего нельзя добиться помещением классов в отдельный модуль.

И здесь я поддерживаю господина still ©. Я ещё не видел таких случаев, где доступ к закрытым членам просто необходим. И многие современные ООП языки это просто не разрешают и ничего, прекрасно существуют. Я за свою жизнь не написал ни одного friend-а (кроме тех случаев когда постигал основы языка) и даже перегруженные операторы я предпочитал делать членами класса.

А то что Делфи имеет такую "фичу" это минус Делфи как языку ООП. И уж точно я не соглашусь с утверждением, что "организация доступа через friend более грамотная". Если вы упёрлись в такую ситуацию, то это всего лишь означает безграммотное проектирование.

← →
qube © (2002-10-11 15:45) [14]

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

← →
han_malign © (2002-10-11 15:50) [15]

не скажите сейчас делаю довольно сложную иерархию обектов разнесенных по разным Unit-ам, и мне нужно чтобы мои объекты имели доступ к полям/методам другого, а конечный пользователь нет(не фиг там делать шаловливым ручкам), без friend-ов даже таких кривых как Delphi - никак.

← →
Ihor Osov'yak © (2002-10-11 16:06) [16]

2 han_malign а prodected кто отменял?

Зы - а если нужен доступ к private за пределами прямого наследования - то стоит призадуматся о кривости проектирования.

← →
Suntechnic © (2002-10-11 16:09) [17]

qube © (11.10.02 15:45)
>даже перегруженные операторы я предпочитал делать членами класса.
а как же симметрия операторов +, -, ...?

Ключевое слово в этой фразе предпочитал. А предпочитал, только лишь потому, что не всегда это возможно. Что касается операторов +,- то я их вообще редко перегружаю.
Я даже больше скажу... многие алгоритмы из STL требуют перегрузки оператора !=. И в некоторых реализациях компиляторов он просто не компиляется, если оператор перегружен как член класса. Это выглядит странно, но это так.

>han_malign © (11.10.02 15:50)
Если Вам нужен доступ к полям другого класса, то вы должны определить public методы для такого доступа. Не вижу причины по которой здесь friend необходим.

2 Suntechnic
Еще раз повторяю, я пишу промежеточное API, объекты должны друг друга видеть почти полностью, а конечный User нет.
Вот взял он модуль - "а что это за метод в Public, если в public, значит для меня и название у него красивое и правильное, мне как раз для полного удовольствия этого метода не хватало ..."- чем закончится использование метода внутреннего использования каждый понимает, а взаимодействие объектов мне необходимо и метод нужен, но в Protected или в Private - если класс еще и наследоваться в будующем может.

Для тех кто пишет фронт-енды friend конечно лишнее, но когда разрабатываешь толстый API на классах - необходим.

>han_malign © (11.10.02 16:22)
Каждый из нас останется при своём мнении. Но лично не наблюдаю никакой необходимости во friend-ах даже для разработки "толстого API на классах"

нужда прижмет - увидишь

> han_malign © (11.10.02 16:42)
> нужда прижмет - увидишь
> Suntechnic © (11.10.02 16:46)
> >han_malign © (11.10.02 16:42)
> Уже прижимала... не видел...

А вот не подеретесь ;)))))))))

ага - он город в анкете не прописал ;))))
как говорится in vina veritas - истина рождается в споре
;^) (я знаю что означает in vina veritas, вот в написании не уверен)

Всем большое спасибо, за обсуждение темы.

Есть ли в Object Pascal friend, как С++ Найти похожие ветки