Форум: "Основная";
Текущий архив: 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.009 c