Klassenbeziehung

hallo
ich bin ein OOP-Anfänger und habe das folgende Problem und bin auf ihre Hilfe angewiesen. Danke
ich habe 3 Klassen ine enem Programm

class A
{
  int xA;
  int funcA();
 // ....etc
}
class B
{
  int xB;
  int funcB();
  //....etc
}
class C
{
  int xC;
  int funcC();
  //....etc
}

die Klasse A benutzt B d.h. innerhalb der Funktion funcA() wird z.B. die Funktion funcB()aufgerufen oder die Variable xB gebraucht.
Die Klasse C benutzt A und B
ich habe im Internet über die Klassenbeziehungen(Aggre. Assz. und Vererb.) gelesen . ich habe das nicht ganz verstanden. aber mir geht es um die Implementierung d.h. wie werden die Objekte erzeugt und die Funktionaufrufe
wie mache ich das?
bitte hilft mir!
vielen Dank

volkard

citizen schrieb:

ich habe im Internet über die Klassenbeziehungen(Aggre. Assz. und Vererb.) gelesen.

eine der drei gibt's in c++ so nicht. entsprechend dürftest du gerade den plan verfolgen, etwas zu machern, das du so gar nicht machen sollst (weil kannst).

Pellaeon

Was soll es davon nicht geben?

Vererbung ist klar.
Bei der Aggregation ergeben mehrere Teile ein Ganzes, wobei die Einzelteile nicht von dem Gesamtobjekt abhängig sind und Assoziation ist einfach ne Beziehung.
Würde man beides z.B per Zeiger machen.

@citizen was du meinst is evtl ne Komposition?
Dann müsste Klasse A aber auch Klasse B wirklich enthalten(also net "int xB;" sondern "B xB";), dann kannst diese Instanz von B innerhalb von A auch benutzen, das gleiche Spiel dann mit Klasse C ... .
Ach ja und wenn die Methoden von außen nnutzbar sein sollen, dann musst du sie public machen, ansonsten has du keinen Zugriff

Mathias

Einfache Erklärung:

In C++ existiert die Vererbung (Klasse erbt von einer anderen), die Assoziation (ein Objekt hält sich einen Pointer auf ein anderes Objekt) und die Komposition (Objekt A beinhaltet besitzt ein Member von Typ B, dieses wird beim Erzeugen von A angelegt und beim Löschen von B zerstört.)
Die Aggregation definiert eine engere Beziehung als die Assoziation, ist allerdings nicht so eng wie die Komposition (Das Objekt von Typ B kann unter Umständen nach dem Ableben von A weiterexistieren).
Alle 4 Varianten lassen sich in C++ abbilden. Das Problem ist, dass die Vererbung die einzige Beziehung ist, die man eindeutig im C++-Code an einer Zeile festmachen kann.
Bei allen anderen anderen Beziehungen (Assoziation, Aggregation oder Komposition) muss immer auch betrachtet werden, wie die Objekte verarbeitet werden.

Einzige Ausnahme hierbei gilt bei folgendem:

KlasseA ObjektA;

Wird eine Variable so innerhalb einer Klasse deklariert, handelt es sich um eine Komposition (feste Bindung).

Wird eine Variable so definiert:

KlasseA * ObjektA;

Ist es von der Implementierung des Zugriffs auf die Variable Abhängig ob es sich um eine Assoziation, Aggregation oder Komposition handelt.

vielen Dank für das schnelle Antworten.
wenn ich das richtig verstanden habe dann geht so:

class A
{
  int xA;
  int funcA();

  B* Obj_b1;    // Objekt vom Typ B-Klasse erzeugen 
  A()     // Konstruktor
  {
     Obj_b1=new B;
  }
  ~A()     // Dekonstruktor
  {
     delete Obj_b1;
  }

 // ....etc
}

Klasse B bleibt unverändert

class B
{
  int xB;
  int funcB();
  //....etc
}

und in der Klasse C zwei Objekte erzeugen

class C
{
  int xC;
  int funcC();

  A* Obj_a;   // Objekt vom Typ A-Klasse erzeugen 
  B* Obj_b2; // Objekt vom Typ B-Klasse erzeugen 
  C()     // Konstruktor
  {
     Obj_a=new A;   
     Obj_b2=new B;
  }
  ~C()     // Dekonstruktor
  {
     delete Obj_a;   
     delete Obj_b2;
  }
  //....etc
}

Die Frage ist: wie kann ich jetzt in der Implemtierung die Funktionsaufrufe und auf die Variablen zugreifen realisieren. etwa so:

A::funcA()
{
 Obj_b1->funcB(); // !!!!!!!!!!!!!!!!ist es richtig
  OBj_b1->xB=12;
}

danke schön

Mathias

Im Prinzip ja.

Man sollte nur bei Pointern stets überprüfen ob sie nicht NULL sind bevor man mit ihnen arbeitet. Außerdem ist es besser Get- bwz. Set-Funktionen für den Zugriff auf Variablen anderer Klassen zu verwenden (durch dieses Vorgehen läßt sich der interne Klassenaufbau zu einem späteren Zeitpunkt besser verändern).

volkard

Mathias schrieb:

Man sollte nur bei Pointern stets überprüfen ob sie nicht NULL sind bevor man mit ihnen arbeitet.

falsch.

Mathias

@volkard
Aha du bist also derjenige, der für die Nullpointerzugriffe verantwortlich ist. ;p