hat-Bezieung guter Stil?
-
Hallo zusammen,
ich selbst habe das noch nie verwendet, doch spricht es für guten Stil (vielleicht steht das ja gar nicht zur Debatte, weil das ganz normaler C++ Standard ist), eine Instanz einer Klasse in der Klassendeklaration einer anderen Klasse zu erstellen (hat-Beziehung)?Vielen Dank
lg, freakC++
-
durchaus üblich
nur darauf achten, dass die untergeordnete Instanz sauber aufgeräumt wird
-
freakC++ schrieb:
eine Instanz einer Klasse in der Klassendeklaration einer anderen Klasse zu erstellen (hat-Beziehung)?
Das ist völlig normal. Im Gegenteil ist es sogar schlechter Stil, wenn du die Eigenschaften einer anderen Klasse nutzen musst und statt ein Member davon zu erstellen von ihr erbst, obwohl es nicht nötig wäre.
-
freakC++ schrieb:
Hallo zusammen,
ich selbst habe das noch nie verwendet, doch spricht es für guten Stil (vielleicht steht das ja gar nicht zur Debatte, weil das ganz normaler C++ Standard ist), eine Instanz einer Klasse in der Klassendeklaration einer anderen Klasse zu erstellen (hat-Beziehung)?Meinst Du so etwas?
class dings { std::string name; // <-- Element ist Objekt einer Klasse ..... };Dagegen ist absolut nichts auszusetzten. Im Gegenteil. "hat-ein" bedeutet für mich, dass das übergeordnete Objekt der Besitzer ist und für die Verwaltung der Lebenszeit zuständig ist. Im obigen Beispiel muss man sich auch gar keine Sorgen machen. Wenn das dings-Objekt zerstört wird, wird auch das name-Element ordnungsgemäß zerstört -- ganz automatisch. Genauso muss man sich auch nicht um's Kopieren oder Zuweisen sorgen.
So eine "hat-ein"-Beziehung kann natürlich auch über Zeiger modelliert werden. Allerdings muss man dann selbst Hand anlegen, was die Verwaltung angeht (eigener copy-constructor, assignment-operator, destructor -- Stichwort: Dreierregel).
Gruß,
SP
-
Hey,
vielen Dank den ausführlichen antworten. Ich erbe also von einer Klasse, wenn sie "thematisch" auch passen...
(wie TBeamter und TLehrer)
Oder so gesagt: Ich erbe, wenn ich die Methoden und Eigenschaften wirklich benötige?!
Vielen Dank
lg, freakC++
-
freakC++ schrieb:
Oder so gesagt: Ich erbe, wenn ich die Methoden und Eigenschaften wirklich benötige?!
Du erbst public, wenn du die "Ist-ein"-Beziehung auch tatsächlich ausnutzen willst, also Laufzeipolymorphie nutzen möchtest. Das geht allerdings nur wenn die Basisklasse virtuelle Methoden, insbesondere einen virtuellen Destruktor hat
Du kannst aus verschiedenen Gründen private oder protected erben, z.B. wenn du protected Elemente der Basisklasse nutzen willst/musst.
Wenn du nur die öffentlichen Methoden und Eigenschaften benötigst reicht Aggregation (also die "hat-ein"-Beziehung).
-
Ich würde es noch stärker verallgemeinern:
Man erhöht die Wartbar- und Erweiterbarkeit eines Programms umso mehr, umso weniger Bindung besteht. Das heißt nicht das man jegliche Bindung vermeiden sollte, aber eine lose Kopplung erleichtert eine nachträgliche Änderung und erlaubt in der Regel auch ein besseren Test (weil man immer kleine Einheiten testen kann).
friend stellt in C++ wohl eine der stärksten Bindungen dar, Vererbung ist die zweitstärkste Bindung. Um so weniger ein Element A von einem Element B kennt bzw. kennen muss, um so niedriger ist die Bindung.
Ich bevorzuge Aggregation/Komposition ("hat/besitzt") der Generalisierung ("ist ein"). Und wenn ich schon Vererbungshierarchien verwende, so versuche ich diese möglichst flach zu halten, sowie wenn sinnvoll und möglich eine reine Schnittstellenvererbung (das was ein Interface in Java/C# ist) zu verwenden.
cu André