ich bastele gerade wieder an meiner Engine und habe jetzt im Kopf, dass man friend vermeiden soll. Aber ich find's eigentlich ganz toll.

A)

Also Sinn macht die Vermeidung imo für friend-Klassen. Ich habe halt ein paar Klassen, die über Factorys erzeugt werden. Diese Klassen sind dann eben mit den zugehörigen Factory-Klassen befreundet. Das finde ich deswegen gut, weil:

1. man die zu erzeugenden Klassen so nicht ohne die Factory erzeugen können soll, was ja gewünscht ist.
2. die Factorys außerdem alle Interna setzen müssen und ich es unschön finde, das alles über Setter und Getter zu lösen (die ja wiederum von anderen Klassen genutzt werden könnten, außer sie wären private)

Häufiger nutze ich jetzt aber befreundete Funktionen. Z.B. habe ich eine CollisionBody-Klasse. Davon erben BoundingSphereTree und AABBTree, es gibt also verschiedene Kollisionsmöglichkeiten.

Jetzt soll ein Baum von BoundingSpheres mit einem Baum von BoundingBoxes kollidieren können usw. Da es nicht soo viele verschiedene Kollisionsobjekte gibt, habe ich das halt mit statischem DoubleDispatching (s. Artikel gelöst). Die Kollisionsfunktionen sollen jetzt natürlich die Interna kennen -> einerseits von den Bäumen, andererseits aber auch von dem Modell, das zu dem Baum gehört. Hintergrund der notwendigen Modell-Informationen ist das Skelett des Modells, das wiederum die Bäume beeinflusst (wenn sich das Skelett durch Animation z.B. bewegt).

Daher finde ich auch hier friend ok. Ich habe halt Abhängigkeiten von Objekten zu freien Funktionen. Das ist ja nicht so schlimm, schätze ich.

Seht ihr da Probleme oder bessere Varianten?

Viel schlimmer finde ich nämlich ein zerbloatetes Interface, das diverse Implementierungsdetails nach aussen reicht, nur um kein friend einsetzen zu müssen. Oder mehrere Funktionen, die das gleiche tun. Dann benutzt man lieber gezielt friend und erhöht sogar die Kapselung.