Designfrage (Sichtbarkeit & Kapselung)



  • auf deutsch: so lassen, wie ichs hatte?



  • dEUs, ich denke nicht daß Du es schaffst um die zusätzlichen Funktionen effektiv herumzukommen - Du schreibst ja selbst, daß Ableitungen zusätzlichen Code benötigen - dieser zusätzliche Code muß plaziert werden - also hast Du eine Funktion, einen Wächter, und dann den Aufruf von m_A.

    Deine Idee mit dem public ist übrigens furchtbar und kann teilweise verbessert werden, wenn Du wenigstens sowas machst:

    class B
    {
    private:
       A m_A;
    public:
       const A& getA() {return m_A;}
    ...
    };
    

    Dies erlaubt nämlich viele Möglichkeiten:
    - Du mußt nicht die ganzen Getter erneut implementieren
    - das Objekt ist wg. const davor geschützt, daß es ohne Wächter beschrieben wird
    - Du kannst im Zweifelsfalle getA sogar noch ändern und eine von A abgeleitete Funktion übergeben, sollte sowas nötig sein



  • Wenn ichs mit GetA mach, hab ich ja immer noch das Problem, dass direkt die Funktionen von A aufgerufen werden und B1 seine zusätzliche Kontrolle nicht machen kann ...



  • Nur die const(!)-Methoden... da brauchst Du im Regelfalle ja keinen guard.

    Ich liefere nur eine const& zurück.



  • Ahso ... Du meinst, dass ihc mit dieser Methode die Getterfunktionen von A nicht in B neu implementieren muss, die restlichen aber schon?



  • Ich dachte an sowas:

    class A
    {
    public:
       int getQ() const;
       int getR() const;
       void doSomething();
       void setQ(int q);
    ...
    };
    class B
    {
    private:
       A m_A;
    public:
       const A& getA() const {return m_A;}
    ...
    };
    
    B myB;
    myB.getA().getQ();
    myB.getA().getR();
    myB.getA().setQ(5); // VERBOTEN
    myB.getA().doSomething(); // VERBOTEN
    

    Du verrätst damit natürlich Details und der Aufrufer kommt an alle const-Methoden von A ohne weitere Kontrolle ran, aber... wie gesagt. Kann eine Lösung sein.



  • Ich verstehe nicht ganz, warum B (und damit B1 usw.) nicht von A erben kann. Du hast in deinem ersten Artikel des Threads ausdrücklich verlangt, daß B jede public-Methode von A ebenfalls besitzen soll. Voila! Genau das ist doch der Fall beim public Vererbung. Oder habe ich da was übersehen?

    Stefan.



  • Im Grunde hast du Recht. Aber irgendwie gefällt mir das net. B ist ja kein ExtendedDirectoryTree, wenn man so will, sondern hat eben nur diese Funktionaläität, zusätzlich zu nem ganzen Haufen anderer Funktionalität ...



  • dEUs schrieb:

    B ist ja kein ExtendedDirectoryTree, wenn man so will, sondern hat eben nur diese Funktionaläität, zusätzlich zu nem ganzen Haufen anderer Funktionalität ...

    Aber doch gerade diese Aussage belegt ja die Anwendung von public-Vererbung. Wenn B tatsächlich die gesamte Funktionalität von B besitzt plus zusätzliche Informationen und Funktionalität, dann ist dies sehr angebracht.



  • Na ok, überredet 😉


Anmelden zum Antworten