Почитай GoF

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

Класс TAHack только делает доступными защещенные методы в другом модуле ( в данном случае модуле наследника ) и он намного менее неправелен, чем возможность вызывать приватные методы в других классах одного модуля.


Кстати описание класса TAHack лучше поместить в раздел implementation.

писатель на коленках, мелких поделок?


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

sCreator, т.е. это бок ОбжектПаскаля? В других языках есть такая возможность?
Ну - что нельзя делать дружественные классы - или как оно там называется.

Не буду сейчас про дружественные. 
Напомню: В последних делфинах уже введен доп модификатор видимости sealed.
В C# (навскидку):
 кроме 3 основных делфийских еще комбинация с internal ( т.е. внутри сборуи ) ( а private только внутри класса, но там в классе можно объявлять вложенные классы ).
Плюс к этому частичные классы, методы расширения ...

Про бок я бы не стал так сразу.

Каждый язык начинается с концепций и развивается.
Delphi в свое время можно сказать из учебно-тренировочного языка сделали передовую среду разработки.
С++ ( ИМХО ) слишком заверчен. НО если учесть, что тогда все ручками, а он позволял двумя символами несколько строк другого языка изобразить...

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

И почему нельзя расширить эту возможность на несколько взаимосвязанных модулей "моим хаком", если разработчик знает что делает.
Кстати при использовании "моего хака" и разнесением потомков в разные модули модель работы получается более логичной. Приватные члены хак не открывает.
И ( если не ошибаюсь ) этот хак я подсмотрел в одном из исходников Delphi.

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

Поскольку в Delphi эту функцию тесной связи классов выполняет модуль, то дружественные классы тут просто не нужны. Соответственно, в Delphi дружественные классы - это классы одного модуля.

Откуда следует, что вопрос "как тогда сделать в Делфи 2 дружественных класса не помещая их в одном модуле?" равносилен "как тогда сделать в C++ 2 дружественных класса не делая их дружественными?"

Ответ: никак (на оба вопроса).

Это сообщение отредактировал(а) CodeMonkey - 31.8.2011, 15:38

Но это же большой минус, если кучу классов (пусть, даже 2) лепить в одном модуле. Модуль разрастается, ориентироваться в нём становится одно удовольствие (ирония).

 
Еще один вопрос скорее по ООП в общем, если в приведённом вначале коде заменить class TB так:



Код компилируется (что логично - модуль один). Для эксперимента написал подобный код в С++ - тоже компиляция. Тогда получается что в данном случае требование



не выполняется. Почему тогда такая двойственность? Логичнее же исключить такую двойственность и быть так: либо нет допуска ко всем другим объектам (даже такого же типа) кроме public, либо ко всем объектам являющимися таким же классом или классом родителя должен быть доступ на уровне protected.

Это сообщение отредактировал(а) rodnover - 31.8.2011, 07:05

Я бы даже сказал: ]"как тогда сделать в C# 2 дружественных класса?" - ответ никак.
Дружественные классы, это C++ и модульности в нем гораздо больше чем в C#. 
В С++ каждый *.cpp компилируется отдельно, так же как в Delphi *.pas. А потом все линкуется.
Я бы сказал: необходимость более тесной связи классов была решена в C++ и Delphi разными способами. 

А теперь добавь к процитированной фразе еще две:
С++:
1. можно обратиться к закрытому члену объекта дружественного класса
2. класс является дружественным сам себе

Delphi:
1. можно обратиться к закрытому члену объекта класс которого описан в том же модуле ( т.е. классы определенные в одном модуле дружественные)
2. описания любых двух объектов одного класса находятся в одном модуле (класс является дружественным сам себе)

Вот твой пример и сработал.