friend vermeiden?
-
Hi,
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:
- man die zu erzeugenden Klassen so nicht ohne die Factory erzeugen können soll, was ja gewünscht ist.
- 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?
-
Solange nicht jeder mit jedem "friend" ist, sehe ich da kein Problem. Aber z.B. 70 Klassen als friend zu deklarieren finde ich etwas übertrieben (hab ich so schon gesehen).
-
70? Also eine hat 70 Klassen-Freunde? Ist ja wie bei Facebook.
-
Ich versuche
friendzwar generell zu vermeiden, aber manchmal ist es wirklich die beste Möglichkeit.Viel schlimmer finde ich nämlich ein zerbloatetes Interface, das diverse Implementierungsdetails nach aussen reicht, nur um kein
friendeinsetzen zu müssen. Oder mehrere Funktionen, die das gleiche tun. Dann benutzt man lieber gezieltfriendund erhöht sogar die Kapselung.
-
Genau, das war mein Gedanke. Die Alternative bestünde in zahlreichen Gettern und Settern. Das bläht die Klasse auf, sieht nicht schön aus und erinnert an Eclipse.
-
hat sich erledigt...