выходил ещё пример: модель ассоциативной операции. например, вычисление силы притяжения между двумя объектами. если делать методом, принимающим в качестве аргумента второй объект, то надо будет сделать в классе доступ к данным о массе, которая другими классами востребована не будет. но, даже если захламленность пространства имен свойствами, используемыми разово, не волнует, то есть ещё проблема логики: от какого объекта отталкиваться? почему при вычислении силы притяжения между Землей и Солнцем надо использовать метод объекта Солнце? разве Земля не притягивает Солнце?! А функция таких вопросов не вызывает - два аргумента; оба равноправные...

Ну-ну... по принципу - вроде, работает и ладно. Ты часто занимался поддержкой и модификацией подобного кода (особенно чужого)?
Это очень плохой подход, поверь...

Я про конкретно указанный случай.
Модификации там быть не может - существует класс, существует документация по методам и свойствам, нечего туда лазить.
Если понадобится модифицировать форму - на указанный участок это никак не повлияет.
Если понадобится добавить новую форму - аналогично (не повлияет).

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

В других случаях, кроме указанного, мне не доводилось использовать друзей класса - всегдя старался обойтись методами класса (и свойствами билдера).



Как раз очень правильный принцип. Работает правильно - не лезь! Иначе работа над проектом превратится в постоянную оптимизацию. Оптимизацию начинай в новой версии продукта, когда старая версия уже работает.

skyboy, дык это не friend-функция, а просто глобальная функция, принимающая объекты. Нет необходимости напрямую лезть и изменять члены-данные участников солнечной системы.


такое ощущение, что вас это распухание радует  


То есть есть класс-менеджер форм, в котором содержится указатель на форму, и формы должны иметь возможность его менять?

Добавлено @ 22:03 
В одной из подчиненных форм создаем метод, принимающий объект класса-менеджера и изменяющий указатель в нем при помощи get/set класса-менеджера. Остальные 9 форм наследуем.

если имеется ввиду перегрузка то это стандартная техника. как раз для



У тебя есть класс A. Класс B пишет сосед Вася Пупкин. Класс B объявлен другом в твоем классе A.  Пришедши домой после корпоративной вечеринки, Вася Пупкин садится за компьютер и устанавливает переменную size твоего массива в -1000.

Добавлено @ 22:20 
А еще лучше, если Вася установит размер массива в -1000 при снятии третьей снизу галки на пятой вкладке твоего приложения. Тогда о новом размере массива узнает уже пользователь  

Это смех сквозь слезы. Нисколечко не радует - так как конца и края нет, а хотелось бы, чтобы хоть что-то заработало. Погоня за универсализмом и всеохватыванием подвела...

Где-то так. Класс содержит логически законченный объет. Есть набор форм, которые позволяют им управлять. При завершении работы форма должна об этом сообщить классу. Из простых методов пришло на ум два: вызов метода класса, если необходимо предпринять дополнительные действия и тупой обнуление указателя на форму, если таковых действий не нужно (например, для форм диагностики). Со стороны "пользователя" можно пользоваться только методами, например ShowSatistic, следовательно сам указатель на форму пользователю видеть не надо, он в protected секции. Вот и родилась идея "друга" чтобы не писать кучу методов из одной строчки F_StatShow = NULL...

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