Getrennte Sichtbarkeitsbereiche für Klassen?
-
Hallo Alle zusammen, gibt es Möglichkeiten Methoden nur für (eine) andere Klasse(n) sichtbar zu machen?
Ich habe eine Klasse Object, welche Methoden, zum setzten von Koordinaten, für eine andere Klasse namens net::Manager zur verfügung stellt. Es passt doch aber nicht so recht ins Information-Hiding-Prinzip, dass diese Methoden allen sichtbar sind...
Eine Friend-Deklaration würde ja den gesamten Private-Bereich offenlegen, also auch nicht das wahre. Kennt jemand ein hilfreiches Sprachmittel?
Modular (mit Namespaces, die Daten und Prozedere zusammenbringen...) würde ich einfach mehere Interface-Dateien mitliefern und den Rest in der Implementierung verstecken, aber das klappt mit Klassen ja leider nicht.
-
Friends.
Gruß
-
FireFlow schrieb:
Friends.
Gruß
Link?
-
-
FireFlow schrieb:
Friends.
Gruß
Quelle: CPPReference.com
friend The friend keyword allows classes or functions not normally associated with a given class to have access to the private data of that class.Ich brauche den Zugriff für eine Klasse auf brstimmte Methoden, nicht auf den ganzen Private-Bereich.
Oder gibt es perhaps eine spezielle Verwendung des Schlüsselwortes?
-
Falls es kein derartiges Sprachmittel geben sollte: hat jemand eine Idee für eine Implementierung?
Oder deutet etwas auf Design-Fehler hin?
-
roan312 schrieb:
Oder deutet etwas auf Design-Fehler hin?
Ja, denn meistens sind schon Friends Anzeichen für Design-Fehler (nicht immer). Zeigt doch einfach mal kurz was du vor hast.
Gruß
-
Getreu dem Motto: Der Weg ist das Ziel habe ich mich daran gemacht ein Spiel zu entwerfen. Das Spielprinzip an sich ist nur soweit wie für das Technische-Design nötig geplan. Wie gesagt geht es mir eher um das sammeln von Erfahrungen beim OO-Design.
Hier die vom Problem betroffenden Teileideen:-Objekte erben von Interfaces, d.h. Alles was übers Netzwerk kommuniziert erbt von einem Net-Interface, Alles was Tastaturevents entgegennehmen kann erbt ...
-Alles ist in Namensbereiche, die sich nach den Interface-Funktionalitäten richten, unterteilt und jeder dieser Namensbereiche hat einen Manager. Dieser führt Listen, die sich ebenfalls nach den Funktionalitäten der Interfaces richten. (vector<NetInterface*> NetList;)
Die Listen werden zu Internen zwecken der jew. Manager (der Netzwerk-M. verbreitet z.B. Koordinationsdaten an die Listen-Objekte) und Anfragen von anderen Managern (z.B. sucht der GUI-Manager ein Objekt, dass auf einen Maus-Klick vom Spieler reagiert) verwendet.Jetzt kommen mir aber Zweifel an dieser Verwendung der Interfaces. Alle Klassen, ob Manager oder Objekt, haben dummerweise Zugriff auf sämtliche Interface-Methoden der Objekte.
Also kann der Laufzeit-Manager munter Koordinaten und Animationen über das NeT-Interface setzen und so weiter...Mir fällt partout keine Möglichkeit ein das Eleganter zu lösen!
OK, das problem hat sich von selbst erledigt... Ich poste dies hier trotzdem, da ich einerseits ~20 Minuten daran geschrieben habe und andererseits die Lösung nennen möchte.
Jeder Manager führt ja Listen von (passendem) Interface*, damit weiß er auch nur von den vom Interface implementierten Methoden.
Ohoh. Das kommt davon, wenn man zu viel Nachdenkt ohne zu Tippen...Vieleicht bemerkt ja noch jemand einige Gravierende Designschnitzer?
Ich wäre über jeden Hinweis dankbar.