Aggregationen und Konstruktoren

1. Mir ist irgendwie nicht ganz bewusst, was das Wort "Aggregation" jetzt genau meint.

Beispielsweise hat man irgendeine geometrische Form, die eine "hat ein" Aggregation zu einem Punkt haben soll (z.B Kreis hat ein Mittelpunkt).

Nun, nach meinem Verständnis hat jetzt halt Kreis eine Member-Variable vom Typ Punkt und sagen wir mal mit dem Namen "mittelpunkt".

Jetzt wurde aber (von Kommilitonen) kritisiert, dass meine Klasse dieser Aggregation nicht nachkommt, weil der Konstruktor meiner Klasse einen Punkt nimmt, anstatt einen x und y-Wert und daraus intern einen Punkt bastelt.

Ich versteh hier den Zusammenhang leider nicht.

2. Was wäre in dem Fall eigentlich eleganter/schöner (unabhängig der Aggregations-Frage) - ein Konstruktor der x und y entgegen nimmt und daraus einen bastelt oder einer, der den Punkt direkt nimmt und somit den Aufrufer dazu zwingt, einen "zu haben"?

Vielleicht war ja das schlecht - wenn ich nur x und y nehme und den Punkt selber erzeuge, dann spare ich mir Überprüfungen auf null.

Aber keine Ahnung, ich find das eigentlich alles total egal, in meinen Augen sind beide Konstruktoren valid und reine Geschmackssache.

TyRoXx

Aggregation schrieb:

Ich versteh hier den Zusammenhang leider nicht.

Es gibt keinen.

Aggregation schrieb:

2. Was wäre in dem Fall eigentlich eleganter/schöner (unabhängig der Aggregations-Frage) - ein Konstruktor der x und y entgegen nimmt und daraus einen bastelt oder einer, der den Punkt direkt nimmt und somit den Aufrufer dazu zwingt, einen "zu haben"?

Zusammengehörige Komponenten zusammenzufassen und das Ganze zu benennen, nennt man Aggregation. Das ist etwas Gutes, weil es die schlechte Art von Redundanzen vermeidet.

Aggregation schrieb:

Vielleicht war ja das schlecht - wenn ich nur x und y nehme und den Punkt selber erzeuge, dann spare ich mir Überprüfungen auf null.

Das mit dem null ist ein anderer Design-Fehler der Sprache selbst. Aggregation ist wichtiger als diesen Fehler zu vermeiden. Eine gute Konvention ist es überhaupt kein null zu verwenden oder zumindest @Nullable und @NotNull hinzuschreiben.

Aggregation schrieb:

Aber keine Ahnung, ich find das eigentlich alles total egal, in meinen Augen sind beide Konstruktoren valid und reine Geschmackssache.

Anfänger deklarieren gerne ihre Fehler als Geschmackssache, weil sie noch nicht wissen, was tatsächlich besser funktioniert.

TyRoXx schrieb:

Es gibt keinen.

Also habe ich die Vorraussetzung, dass die Klasse Kreis eine "Hat ein"-Aggregation zur Klasse Punkt haben soll nicht verletzt, indem mein Konstruktor einen Punkt nimmt, anstatt zwei double-Werte und daraus intern einen baut?

TyRoXx schrieb:

Zusammengehörige Komponenten zusammenzufassen und das Ganze zu benennen, nennt man Aggregation. Das ist etwas Gutes, weil es die schlechte Art von Redundanzen vermeidet.

Okay, klingt gut.

TyRoXx schrieb:

Das mit dem null ist ein anderer Design-Fehler der Sprache selbst. Aggregation ist wichtiger als diesen Fehler zu vermeiden. Eine gute Konvention ist es überhaupt kein null zu verwenden oder zumindest @Nullable und @NotNull hinzuschreiben.

Hm, klingt auch wieder so als hätte ich es richtig gemacht.

volkard

Aggregation schrieb:

1. Mir ist irgendwie nicht ganz bewusst, was das Wort "Aggregation" jetzt genau meint.

Der Witz an diesem Wort ist, daß keiner die genaue Bedeutung weiß. Anleitungen, wie man Aggregationen in UML-Klassen(struktur)diagramme zu malen hat widersprechen den Codebeispielen und beide widersprechen den Datenbanktabellen.

volkard schrieb:

Aggregation schrieb:

1. Mir ist irgendwie nicht ganz bewusst, was das Wort "Aggregation" jetzt genau meint.

Der Witz an diesem Wort ist, daß keiner die genaue Bedeutung weiß. Anleitungen, wie man Aggregationen in UML-Klassen(struktur)diagramme zu malen hat widersprechen den Codebeispielen und beide widersprechen den Datenbanktabellen.

Das hatte ich fast befürchtet. Wenn es so schwammig definiert ist, dann kann es eventuell auch sein, dass es tatsächlich irgendwas mit dem Konstruktor zu tun hat.

Ich wühl mich mal durch das Skript des Dozenten, vielleicht finde ich dort seine Definition des Begriffes.
Kann mir aber irgendwie kaum vorstellen, dass das irgein sinnvoler Stil wäre.

Also ich fand mein Konstruktor so i.O. und werde ihn wohl auch in Zukunt so schreiben.

volkard schrieb:

Der Witz an diesem Wort ist, daß keiner die genaue Bedeutung weiß.

Was ist denn an der üblichen Definition falsch?

volkard

Wiki-Leser schrieb:

volkard schrieb:

Der Witz an diesem Wort ist, daß keiner die genaue Bedeutung weiß.

Was ist denn an der üblichen Definition falsch?

Welche übliche Definition?

Dieser Artikel wurde wegen inhaltlicher Mängel auf der Qualitätssicherungsseite der Redaktion Informatik eingetragen. Dies geschieht, um die Qualität der Artikel aus dem Themengebiet Informatik auf ein akzeptables Niveau zu bringen. Hilf mit, die inhaltlichen Mängel dieses Artikels zu beseitigen, und beteilige dich an der Diskussion! (+)
Begründung: Müsste deutlich verständlicher werden; teilweise braucht der Artikel einfach ein paar mehr Erklärungen. Man beachte bei der Überarbeitung auch Aggregation (OLAP)! --Michileo 07:57, 2. Nov. 2011 (CET)

volkard schrieb:

Welche übliche Definition?

Die da:

In der objektorientierten Programmierung spezifiziert die Aggregation eine Assoziation zwischen Objekten. Im Gegensatz zur Komposition (die ebenfalls eine „ist-Teil-von“-Assoziation beschreibt) kann das Teil-Objekt ohne das Aggregat-Objekt existieren; Es wird also nicht automatisch beim Löschen des Aggregat-Objekts mitgelöscht.

der QS-Baustein scheint sich primär um den Datenbank-Teil zu drehen.

volkard

Wiki-Leser schrieb:

volkard schrieb:

Welche übliche Definition?

Die da:

In der objektorientierten Programmierung spezifiziert die Aggregation eine Assoziation zwischen Objekten. Im Gegensatz zur Komposition (die ebenfalls eine „ist-Teil-von“-Assoziation beschreibt) kann das Teil-Objekt ohne das Aggregat-Objekt existieren; Es wird also nicht automatisch beim Löschen des Aggregat-Objekts mitgelöscht.

Mhhm. Also ein Bein, das weiterlebt, wenn Otto überfahren wird. Dann hat Otto nur einen Zeiger auf sein Bein. Aber dann verschwindet das Bein ja nicht per RAII automatisch. Dann ist doch das Programm kaputt?

Ich versteh nicht ganz worauf du hinaus willst.

Es beschreibt doch noch nur abstrakt, wie die beiden Objekte miteinander verknüpft sind.
Bei einer Aggregation ist impliziert dass das Aggregat-Objekt ("Otto" in deinem Fall, der Kreis in OPs Fall) eine Möglichkeit haben muss, das Teil-Objekt übergeben zu bekommen.
Andernfalls eben genau nicht, weil es sich selbst um die Instantiierung und die spätere Löschung kümmert.