Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Основная";
Текущий архив: 2002.10.24;
Скачать: [xml.tar.bz2];

Вниз

Есть ли в 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 необходим.


 
Anatoly Podgoretsky   (2002-10-11 16:11) [18]

still © (11.10.02 10:41)
Правильно, поэтому ни проблем ни горя с этим не имею.


 
han_malign   (2002-10-11 16:22) [19]

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

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


 
Suntechnic   (2002-10-11 16:24) [20]

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


 
han_malign   (2002-10-11 16:42) [21]

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


 
Suntechnic   (2002-10-11 16:46) [22]

>han_malign © (11.10.02 16:42)
Уже прижимала... не видел...


 
NailS   (2002-10-11 16:57) [23]


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


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


 
han_malign   (2002-10-11 17:06) [24]

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


 
Tihas   (2002-10-11 23:18) [25]

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



Страницы: 1 вся ветка

Форум: "Основная";
Текущий архив: 2002.10.24;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.5 MB
Время: 0.007 c
3-78272
lutikh
2002-10-02 22:23
2002.10.24
Много таблиц (.dbf). Выбрать одну позицию.


14-78655
sancho
2002-10-04 21:38
2002.10.24
Help для RxLib


3-78219
Андрусь
2002-10-03 19:29
2002.10.24
Помогите разобраться с форматной маской


14-78634
Kim
2002-10-03 14:20
2002.10.24
Password ACCESS


1-78494
AndrX.
2002-10-13 17:06
2002.10.24
Вывод сообщения по времени указанному в...





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский