Pattern für öffentlichen Zugriff auf öffentliche Schnittstellen von private Membern

[notsmart]

SeppJ schrieb:

Das "Ist ein"-Konzept wird, wie du korrekt beschreibst, durch private-Vererbung umgesetzt. Du hast aber ein "Hat ein"-Konzept eingesetzt.

Sorry, ich habe jetzt zwei Fragen die ich parallel in zwei Posts posten wollte durcheinander gebracht. Ist wohl noch zu früh. Danke für den Hinweis

Gibt es dennoch irgendwie was besseres als Funktionen durchzuschleifen oder soll ich ich:

class A : public B

[Michael E.]

SeppJ schrieb:

Das "Ist ein"-Konzept wird, wie du korrekt beschreibst, durch private-Vererbung umgesetzt. Du hast hier aber ein "Hat ein"-Konzept durch Komposition eingesetzt.

Bin ich noch nicht richtig wach?

notsmart: Die übliche Vererbungsmethode ist public.

[SeppJ]

Michael E. schrieb:

SeppJ schrieb:

Das "Ist ein"-Konzept wird, wie du korrekt beschreibst, durch private-Vererbung umgesetzt. Du hast hier aber ein "Hat ein"-Konzept durch Komposition eingesetzt.

Bin ich noch nicht richtig wach?

notsmart: Die übliche Vererbungsmethode ist public.

Nein, ich war noch nicht richtig wach.

[CStoll]

Nochmal langsam:
"Ist ein" wird durch öffentliche Vererbung umgesetzt - das heißt mit class A : public B{...} drückt du aus, daß A überall eingesetzt werden kann, wo B erwartet wird.
Du hast dort eine "hat ein"-Beziehung. Und normalerweise ist die Tatsache, welche Hilfsobjekte A tatsächlich verwendet, nur irgendwo intern relevant. Wenn du einen Grund hast, aus A heraus die Innereien seiner Hilfsobjekte offenzulegen, dann kannst du es gerne explizit machen. Aber eventuell solltest du mal genauer erklären, was du eigentlich vorhast.

[SeppJ]

notsmart schrieb:

Gibt es dennoch irgendwie was besseres als Funktionen durchzuschleifen oder soll ich ich:

class A : public B

Bei den ganzen Vererbungssachen geht es nicht (nur) um das technische Durchschleifen. Denk objektorientiert wie du etwas modellieren würdest und setz dann dieses Modell um. Wenn dein A ein B hat, dann mach Komposition wie oben. Normalerweise ist es dann auch gar nicht mehr nötig, einzeln die Eigenschaften von B abzufragen, denn das B ist ja ein Teil von A und somit seiner Eigenschaften. Wenn das nicht so ist, dann war die Modellierung "A hat ein B" wohl nicht so gut und vielleicht ist A ein B.

Wenn man nicht nur von A und B redet, sondern von konkreten Dingen, dann ist meistens ziemlich klar wie sie sich zueinander Verhalten:
http://www.c-plusplus.net/forum/75672

[notsmart]

Es geht um Orientierungen von zueinander in Bezug stehenden Kameras wobei jede Kamera eigene Parameter (Kamerakonstante,Hauptpunkt,Verzeichnungen) hat.

also habe ich folgenden "ähnlichen" Code:

class Kamera
{
  private:
    double focalLength;
    // ... usw
  public:
   double GetFocalLength() const { return focalLength; }
   void   SetFocalLength(double c) const
   {
     if(c > 0)
     {
       focalLength = c;
       return;
     }
     // ...
   }
}

class RO
{
  private:
   vector<Kamera> cams;
   // weitere member
  public:
   bool calculate();
}

Dann gibt es weitere Klassen wie Absolute und Äußere Orientierung die alle auf die Kameradaten mit const Get zugreifen möchten.

[Eisflamme]

Wollen die auf eine bestimmte Kamera zugreifen oder ist es völlig willkürlich und RO auch nicht bekannt, welche das sind?

[notsmart]

Eisflamme schrieb:

Wollen die auf eine bestimmte Kamera zugreifen oder ist es völlig willkürlich und RO auch nicht bekannt, welche das sind?

Sagen wir mal so selbst wenn der Vector weg "wäre", würde ich gerne auf die Kamera frei zugreifen wollen. Anscheinend gibt es aber da kein sinnvolles Konzept außer vielleicht protected vererbung.

[CStoll]

Was mir eventuell einfallen würde, wäre eine Zugriffsmethode um die Kamera(s) erreichen zu können:

class RO
{
private:
  vector<Kamera> cams;
  // weitere member
public:
  bool calculate();
  Kamera& getKamera(size_t i) { return cams.at(i); }
};

Vererbung ist definitiv keine Universal-Lösung und sollte nur dann eingesetzt werden, wenn es unbedingt erforderlich ist

[notsmart]

CStoll schrieb:

Was mir eventuell einfallen würde, wäre eine Zugriffsmethode um die Kamera(s) erreichen zu können:

class RO
{
private:
  vector<Kamera> cams;
  // weitere member
public:
  bool calculate();
  Kamera& getKamera(size_t i) { return cams.at(i); }
};

Vererbung ist definitiv keine Universal-Lösung und sollte nur dann eingesetzt werden, wenn es unbedingt erforderlich ist

Für mich impliziert Get immer const zeiger oder const referenz. Macht man das tatsächlich so wie du es oben beschreibst? Damit kannst du Kamera genau so in den public Bereich schieben weil man damit die Datenkapselung unterwandert. Ich habe da aber nicht so die Erfahrung. Sammle daher Anregungen.

[CStoll]

Du willst dem Nutzer doch Zugriff auf die Methoden der Member anbieten. Das heißt, du mußt entweder die Methoden selber schreiben und an die Kamera(s) weiterleiten oder du gibst dem Nutzer Direktzugriff auf die Kamera, damit er deren Methoden aufrufen kann.

PS: Wenn du dir Sorgen über die Kapselung machst, warum kommst du dann mit Vererbungs-Lösungen?

[Eisflamme]

Meine Frage zielte darauf, wozu diese Klasse, die Kameras im Vektor verwaltet überhaupt da ist. Sinn macht für mich, wenn diese den Zugriff in der Form kapselt, dass es z.B. eine aktive Kamera gibt oder hier Kameras für verschiedene Viewports eingestellt werden können usw.

Wenn das Ding aber eine derartige Organisationskraft hat, wäre es fatal diese durch einen einfachen Getter zu unterwandern. Und wenn die Klasse nichts dergleichen tut, stellt sich mir die Frage, wozu es diese Klasse eigentlich gibt.

Was ist deren genaue Verantwortlichkeit?