7
OOP und Komposition im Klassendiagramm
Hallo.
meine Frage bezieht sich auf die Komposition als Ganze-Teile-Beziehung im OOP-Paradigma.
In Lehrbüchern wird immer mal wieder behauptet, dass Klassen wie Abteilung und Mitarbeiter eine Aggregation bilden, weil Abteilungen aufgelöst werden können ohne dass dabei die Existenz der Mitarbeiter berührt wird.
Ich empfinde es allerdings so, dass hier fälschlicherweise die Eigenschaften von Realweltobjekten auf Software-Klassen übertragen wird. Hinsichtlich der Software sind doch die Kundenanforderungen maßgeblich und nicht das Verhalten der Realweltobjekte.
Es könnte z. B. sein, dass die Klasse Abteilung eine Modell-Klasse ist, die mithilfe eines ORM-Frameworks zur Laufzeit instanziiert wird und alle zugehörigen Mitarbeiter als Liste enthält.
Ist die Operation auf die Datensätze beendet und wird das Objekt der Klasse Abteilung wieder gelöscht, sind auch alle Mitarbeiter weg.
Wie seht ihr das?
meine Frage bezieht sich auf die Komposition als Ganze-Teile-Beziehung im OOP-Paradigma.
In Lehrbüchern wird immer mal wieder behauptet, dass Klassen wie Abteilung und Mitarbeiter eine Aggregation bilden, weil Abteilungen aufgelöst werden können ohne dass dabei die Existenz der Mitarbeiter berührt wird.
Ich empfinde es allerdings so, dass hier fälschlicherweise die Eigenschaften von Realweltobjekten auf Software-Klassen übertragen wird. Hinsichtlich der Software sind doch die Kundenanforderungen maßgeblich und nicht das Verhalten der Realweltobjekte.
Es könnte z. B. sein, dass die Klasse Abteilung eine Modell-Klasse ist, die mithilfe eines ORM-Frameworks zur Laufzeit instanziiert wird und alle zugehörigen Mitarbeiter als Liste enthält.
Ist die Operation auf die Datensätze beendet und wird das Objekt der Klasse Abteilung wieder gelöscht, sind auch alle Mitarbeiter weg.
Wie seht ihr das?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3486227009
Url: https://administrator.de/forum/oop-und-komposition-im-klassendiagramm-3486227009.html
Ausgedruckt am: 22.12.2024 um 17:12 Uhr
7 Kommentare
Neuester Kommentar
Hi,
Wenn ich das richtig in Erinnerung habe, dann spricht man von Komposition, wenn existenzbegründende Abhängigkeiten bestehen. Also wenn Objekt "lebender Baum" zerstört wird, dann kann Objekt "lebendes Blatt" nicht allein weiterexistieren. Zumindest nicht als "lebendes" Blatt.
Insofern widerspricht sich o.g. Aussage in sich selbst. Etwas kann nicht eine Komposition sein, weil ein "untergeordnetes" Objekt ohne das "übergeordnete" Objekt weiterbestehen kann.
Und auf Dein Beispiel bezogen:
Das muss nicht so sein.
Es können 2 unabhängige Listen bestehen, in welchen dieselben Mitarbeiter enthalten sind. Eine Liste "Abteilung A" und eine Liste "Kantine Menü A". Wenn am Mittwoch die Abteilung A aufgelöst wird, dann werden die Mitarbeiter trotzdem am Donnerstag noch das bestellte "Menü A" in der Kantine essen wollen. Also müssen die Mitarbeiter-Objekte nach dem Löschen des "Abteilung A"-Objekts weiterhin bestehen bleiben, weil sie in der Liste "Kantine Menü A" weiterhin referenziert sind.
Es wäre unpraktisch und auch unnötig, jetzt jeweils zwei Objekte pro Mitarbeiter zu erstellen, welcher in beiden Listen enthalten sein sollen. Zumal dann Aktionen mit einem solchen Mitarbeiter dann nicht in beiden Listen Auswirkungen hätten. z.B. "Mitarbeiter verstorben". Wenn ich das in der Abteilung bekanntgebe, danach die Abteilung lösche, dann wäre diese Information weg und die Kantine wüsste davon nichts.
E.
dass Klassen wie Abteilung und Mitarbeiter eine Komposition bilden, weil Abteilungen aufgelöst werden können ohne dass dabei die Existenz der Mitarbeiter berührt wird.
Entweder hast Du Dich da verschrieben oder die Aussage ist so schon vom Grundsatz her unlogisch.Wenn ich das richtig in Erinnerung habe, dann spricht man von Komposition, wenn existenzbegründende Abhängigkeiten bestehen. Also wenn Objekt "lebender Baum" zerstört wird, dann kann Objekt "lebendes Blatt" nicht allein weiterexistieren. Zumindest nicht als "lebendes" Blatt.
Insofern widerspricht sich o.g. Aussage in sich selbst. Etwas kann nicht eine Komposition sein, weil ein "untergeordnetes" Objekt ohne das "übergeordnete" Objekt weiterbestehen kann.
Und auf Dein Beispiel bezogen:
Das muss nicht so sein.
Es können 2 unabhängige Listen bestehen, in welchen dieselben Mitarbeiter enthalten sind. Eine Liste "Abteilung A" und eine Liste "Kantine Menü A". Wenn am Mittwoch die Abteilung A aufgelöst wird, dann werden die Mitarbeiter trotzdem am Donnerstag noch das bestellte "Menü A" in der Kantine essen wollen. Also müssen die Mitarbeiter-Objekte nach dem Löschen des "Abteilung A"-Objekts weiterhin bestehen bleiben, weil sie in der Liste "Kantine Menü A" weiterhin referenziert sind.
Es wäre unpraktisch und auch unnötig, jetzt jeweils zwei Objekte pro Mitarbeiter zu erstellen, welcher in beiden Listen enthalten sein sollen. Zumal dann Aktionen mit einem solchen Mitarbeiter dann nicht in beiden Listen Auswirkungen hätten. z.B. "Mitarbeiter verstorben". Wenn ich das in der Abteilung bekanntgebe, danach die Abteilung lösche, dann wäre diese Information weg und die Kantine wüsste davon nichts.
E.
@emeriks
Ich habe mich verschrieben. Ich meinte, dass in den Lehrbüchern Abteilung und Mitarbeiter grundsätzlich als eine Aggregation angenommen wird, weil es in der Realwelt so ist.
Ich habe mich verschrieben. Ich meinte, dass in den Lehrbüchern Abteilung und Mitarbeiter grundsätzlich als eine Aggregation angenommen wird, weil es in der Realwelt so ist.
Dann ist doch Deine Frage damit obsolet geworden oder ist da jetzt noch etwas anderes unklar?
Ist die Operation auf die Datensätze beendet und wird das Objekt der Klasse Abteilung wieder gelöscht, sind auch alle Mitarbeiter weg.
Wie seht ihr das?
Wie seht ihr das?
Anders.
Wenn es eine Anforderung ist, dann ja. In ORMs definiert man dann eine entsprechende Abhängigkeit in Form von "kaskadierendem Löschen", womit dann bei einem Löschen eines Abteilungs-Objekts alle verbundenen Mitarbeiter-Objekte auch gelöscht werden.
In der realen Welt wäre so eine Anforderung eher ungewöhnlich. Man würde dann im ORM auf die Verknüpfung mit dem kaskadierenden Löschen verzichten. Zudem kann es vorkommen, dass Mitarbeiter auch zu mehreren Abteilungen gehören. Hängt aber von weiteren Eigenschaften der Organisationseinheiten ab.
Beispiel: Betriebsratsmitglieder gehören dem Betriebsrat an und einer Abteilung. Der feuchte Traum der Unternehmen würde wahr, wenn man jetzt die Abteilung "löscht" und damit die Betriebsratsmitglieder automatisch loswerden würde
)Ich behaupte, dass die Abstraktion der Daten und Klassen und die Überführung in ein ORM eine hohe Kunst ist und keinem "Schema F" aus Büchern folgen kann. Man sollte sich sehr viel Zeit nehmen und mehrere Modelle durchspielen, bis man das (hoffentlich) optimale entwickelt hat.
Mir ist es wichtig, zu betonen, dass ich weder der Meinung bin, dass dieses Beispiel eine klassische Komposition ist noch eine klassische Aggregation.
Mir ist nur aufgefallen, dass dieses Beispiel häufig zur Erklärung von Aggregation herangezogen wird, weil die Existenz der Mitarbeiter ja nicht endet nur weil die Abteilung aufgelöst wird. So verhält es sich jedenfalls in der realen Welt.
Nun empfinde ich es aber als falsch, das UML-Klassendiagramm auf das Verhalten von Realweltobjekten zu beziehen. Manch einer mag das für didaktisch sinnvoll ansehen. Ich bin jedoch der Meinung, dass es für die Modellierung von Softwarearchitekturen vorgesehen ist und die können sich von der realen Welt erheblich unterscheiden. Wer versucht Realweltobjekte mit dem Klassendiagramm zu beschreiben, der reißt das Diagramm aus seinem Kontext.
Mir ist nur aufgefallen, dass dieses Beispiel häufig zur Erklärung von Aggregation herangezogen wird, weil die Existenz der Mitarbeiter ja nicht endet nur weil die Abteilung aufgelöst wird. So verhält es sich jedenfalls in der realen Welt.
Nun empfinde ich es aber als falsch, das UML-Klassendiagramm auf das Verhalten von Realweltobjekten zu beziehen. Manch einer mag das für didaktisch sinnvoll ansehen. Ich bin jedoch der Meinung, dass es für die Modellierung von Softwarearchitekturen vorgesehen ist und die können sich von der realen Welt erheblich unterscheiden. Wer versucht Realweltobjekte mit dem Klassendiagramm zu beschreiben, der reißt das Diagramm aus seinem Kontext.
@Enrixk
Im Prinzip hast Du da recht. Allerdings bezieht sich das generell auf alle Abbildungen der realen Welt. Und eine Programm oder Daten, welche die reale Welt widerspiegeln sollen, sind nun mal nur Abbildungen derer.
Streng genommen müsste man - wenn, dann - das OOP mit den bisherigen Systemen zum Abbilden der realen Welt vergleichen und nicht mit der Welt selbst.
Im Prinzip hast Du da recht. Allerdings bezieht sich das generell auf alle Abbildungen der realen Welt. Und eine Programm oder Daten, welche die reale Welt widerspiegeln sollen, sind nun mal nur Abbildungen derer.
Streng genommen müsste man - wenn, dann - das OOP mit den bisherigen Systemen zum Abbilden der realen Welt vergleichen und nicht mit der Welt selbst.
Also ich hätte da jetzt Probleme mit, wenn sich die reale Welt den OO-Diagrammen zu beugen hat, weil das irgendwer in der Theorie zwischen Graphentheorie und bunten Bildchen so festgelegt hat.
Softwarearchitekturen, die der realen Welt nachempfunden sind, sind mir irgendwie lieber. Alles andere hört sich eher nach dem blinden Befolgen von Theorien an. Zudem können einem unterschiedliche Programmiersprachen und Datenbanken unterschiedliche Streiche spielen, die ein Umsetzen eines theoretischen UML-Diagramms in echten Code oder echte Datenbankobjekte unmöglich machen. Man hat es dann vielleicht wunderbar theoretisch erklärt, löst aber kein Problem damit. Und da sehe ich eher das Einsatzgebiet von UML-Diagrammen: Probleme lösen und nicht noch welche schaffen.
Softwarearchitekturen, die der realen Welt nachempfunden sind, sind mir irgendwie lieber. Alles andere hört sich eher nach dem blinden Befolgen von Theorien an. Zudem können einem unterschiedliche Programmiersprachen und Datenbanken unterschiedliche Streiche spielen, die ein Umsetzen eines theoretischen UML-Diagramms in echten Code oder echte Datenbankobjekte unmöglich machen. Man hat es dann vielleicht wunderbar theoretisch erklärt, löst aber kein Problem damit. Und da sehe ich eher das Einsatzgebiet von UML-Diagrammen: Probleme lösen und nicht noch welche schaffen.
