2016-11-22 6 views
1

Ich versuche, eine elegante Lösung für das Problem zu finden, mehrere Schnittstellen zu einer Klasse in C++ anzubieten. Angenommen, wir haben die Klassen B, C und D. B und C benötigen einen benutzerdefinierten/kontrollierten Zugriff auf die Klasse A, während D direkten Zugriff haben kann. Die Lösung für solche Schnittstellen muss erweiterbar sein. Zukünftige Schnittstellen sind möglicherweise nur für eine bestimmte Klasse spezialisiert.Mehrere Schnittstellen zu einer Klasse

Momentan erstelle ich Interfaceklassen (IA_1, IA_2), die eine Referenz auf die Klasse A haben. B und C werden mit Instanzen dieser Interfaces bereitgestellt und können auf A bis IA_1 bzw. IA_2 individuell/kontrolliert zugreifen. Die Situation ist im Bild unten dargestellt.

enter image description here

Dies hat den Vorteil, dass ich nicht brauchen, Klasse A zu berühren, wenn eine neue Schnittstelle zu implementieren. Neue Schnittstellen können alte Schnittstellen durch Vererbung nutzen. Klassen, die Zugriff auf A benötigen, können dies nur über ihre spezielle Schnittstelle tun.

Die Implementierung in C++ würde wie folgt aussehen:

class A{ 
public: 
    void foo(); 
}; 

class IA_1{ 
public: 
    void foo(const B& b); 
private: 
    std::weak_ptr<A> m_A; 
}; 

class IA_2{ 
public: 
    void foo(); 
private: 
    std::weak_ptr<A> m_A; 
}; 

class B{ 
    std::unique_ptr<IA_1> m_A; 
}; 

class C{ 
    std::unique_ptr<IA_1> m_A; 
}; 

class D{ 
    std::weak_ptr<A> m_A; 
}; 

Die Schnittstellen bekommen weak_ptr zu A, weil ich Klassen nicht will, das nur A zugreifen, in seinem gesamten Lebensdauer-Management teilzunehmen.

Momentan erstelle ich ein Interface-Objekt für jede Instanz von B oder C, obwohl alle dasselbe tun. Ich habe bereits darüber nachgedacht, nur ein Interface-Objekt zu erstellen und gebe jeder Instanz von B und C eine Referenz (shared_ptr) der entsprechenden Schnittstelle. Auf diese Weise habe ich nur ein Objekt für jede Schnittstelle. Vielleicht ist dies bereits ein Fall einer vorzeitigen Optimierung, um den Speicherbedarf der Anwendung zu reduzieren.

Gibt es eine Möglichkeit, dieses Design weiter zu verbessern oder einen völlig anderen Ansatz zu verfolgen?

+1

Ihre UML ist verwirrend, weil die Verbindungslinien umgekehrt sind ([siehe Wikipedia] (https: //en.wikipedia.org/wiki/Object_composition # UML_notation)) – stefaanv

+0

Scheint mir eher eine vorzeitige Pessimierung. N schwache Zeiger auf ein Objekt zu haben ist besser als N gemeinsame Zeiger auf einen schwachen Zeiger auf ein Objekt zu haben. – user2079303

+0

@stefaanv Sie haben Recht. Ich habe das UML-Diagramm korrigiert. – Stan

Antwort

2

Wahrscheinlich keine vollständige Antwort, nur meine Gedanken.

Nachteile:

  • Zusätzliche Schnittstellenklassen
  • Extra-indirection eingeführt, mit extra Wartung pro unterstützt Aufruf
  • Konstruktion: extra Fabrik für die Schnittstelle benötigt zeigen
  • schwachen Zeiger auf Objekt: den Fall lösen wo der Zeiger baumelt

Pro:

  • klare Kontrolle über die Schnittstelle der Klasse
  • zusätzliche Sicherheit über die gesamte Lebensdauer (überprüft werden kann, sollte aber auch behandelt werden) auf dem Objekt benötigt
  • begrenzte Änderung (Freunde?)

Über Die 1 Instanz pro Schnittstelle: Der Footprint wird etwas niedriger sein, aber Sie benötigen zusätzliche Verwaltung für den Zugriff auf diese 1 Instanz.

Verwandte Themen