30. Juni 200916 j Hallo, wer kann mir in Form von C# Code die Objekt-Beziehungen Assoziation, Aggregation, Komposition und assoziative Klassen erklären? Der Unterschied ist klar und in UML ist das Ganze auch kein Problem aber am Beispiel von C#-Code konnte ich leider nichts finden. Vielen Dank schon mal im Voraus!!!
2. Juli 200916 j Ganz banal könnte eine Assoziation einfach mal so aussehen: class Person { [INDENT]Address TheAddress;[/INDENT] } class Address { [INDENT]string Town;[/INDENT] [INDENT]string Street;[/INDENT] . . . } Das Beispiel währe dann eine gerichtete Assoziation, d.h. eine Klasse enthält ein Member, das auf das Objekt einer anderen Klasse referenziert. Alle Arten von Assoziationen werden von in C# nicht mit Hilfe irgendwelcher Schlüsselwörter, sondern mit Hilfe einer bestimmten Logik implementiert. Assoziation (UML) ? Wikipedia Abschließend kann ich dir nur noch einen guten Rat mit auf den Weg geben: Je weniger UML desto besser! Uml ist ein schönes Hilfsmittel um Architekturen zu erklären und um sich Beziehungen beim Engineering zu visualisieren, aber diese Diagramme ändern sich fortlaufend und haben wenn überhaupt nur etwas in Dokumentationen abgeschlossener Projekte verloren. Achja eine Assoziative Klasse wäre z.B. die implementierung eines MEDIATOR Patterns
3. Juli 200916 j Das Beispiel währe dann eine gerichtete Assoziation, d.h. eine Klasse enthält ein Member, das auf das Objekt einer anderen Klasse referenziert. Das wäre sogar eine Aggregation. Eine Assoziation ist doch schon, wenn man aus einer fremden Klassen Methoden aufruft. Oder täusch ich mich da grad?! :beagolisc
3. Juli 200916 j ja da täuscht du dich, wenn eine Klasse statische Member einer anderen aufruft oder wie gesagt nur die Methoden eines Objekts, das als Parameter reingeschoben wird aufruft, dann ist das nur eine Abhängigkeit und wird mit einem gestrichelten Pfeil dargestellt imo
3. Juli 200916 j Vielen Dank für die Antworten!!! So ähnlich habe ich mir eine Assoziation auch vorgestellt: public class Mann { Frau ehefrau; public Mann() { ehefrau = null; } public Frau Ehefrau { get { return ehefrau; } set { ehefrau = value; } } } public class Frau { Mann ehemann; public Frau() { ehemann = null; } public Mann Ehemann { get { return ehemann; } set { ehemann = value; } } } Für eine Aggregation habe ich mir das hier ausgedacht: public class Obst { string farbe; string form; public string Farbe { get { return farbe; } set { farbe = value; } } public string Form { get { return form; } set { form = value; } } } public class Apfel : Obst { string geschmack; public string Geschmack { get { return geschmack; } set { geschmack = value; } } } public class Birne : Obst { string groesse; public string Groesse { get { return groesse; } set { groesse = value; } } } public class Obstkorb { List<Obst> inhalt; public Obstkorb() { inhalt = new List<Obst>(); } public readonly List<Obst> Inhalt { get { return inhalt; } } } Hierbei liegt die Aggregation in der Beziehung der Äpfel innerhalb des Obstkorbes. Diese sind Teile vom Obstkorb aber wenn der Obstkorb zerstört wird, existieren die Äpfel und Birnen weiterhin...richtig? Und hier meine Vorstellung einer Komposition: public class Koerper { Kopf kopf; Herz herz; public Koerper() { kopf = new Kopf(this); herz = new Herz(this); } public Kopf Kopf { get { return kopf; } } public Herz Herz { get { return herz; } } } public class Kopf { public Kopf(Koerper koerper) { if (koerper == null) { // Exception Kein existierender Körper } else { if (koerper.Kopf != null) { // Exception Körper hat schon einen Kopf } } } } public class Herz { public Herz(Koerper koerper) { if (koerper == null) { // Exception Kein existierender Körper } else { if (koerper.Herz != null) { // Exception Körper hat schon ein Herz } } } } Bei der Komposition bricht mein Wahnsinn mal wieder aus.....ich habe ein wenig Gott gespielt . Ohne Körper, kein Kopf und kein Herz. Was haltet ihr davon?
3. Juli 200916 j Also ich sags dir gleich: Jeder versteht was du meinst auch ohne die Sonderfälle Aggregation und Komposition... UML wird sehr sehr überbewertet. Am wichtigsten ist immernoch der Code!
6. Juli 200916 j UML wird sehr sehr überbewertet. UML ist aber sprachunabhängig. Jemand der kein C# kann, wird den Code auf anhierb sicher nicht verstehen. Außerdem ist UML bei Projekten mit mehreren hundert Klassen eine bessere Übersicht als jeder Code.
6. Juli 200916 j s.o. Abschließend kann ich dir nur noch einen guten Rat mit auf den Weg geben: Je weniger UML desto besser! Uml ist ein schönes Hilfsmittel um Architekturen zu erklären und um sich Beziehungen beim Engineering zu visualisieren, aber diese Diagramme ändern sich fortlaufend und haben wenn überhaupt nur etwas in Dokumentationen abgeschlossener Projekte verloren. und werft mal nen Blick da drauf: clean-code-developer - Trac
6. Juli 200916 j Uml ist ein schönes Hilfsmittel um Architekturen zu erklären und um sich Beziehungen beim Engineering zu visualisieren, aber diese Diagramme ändern sich fortlaufend Für sowas gibts die Planungsphase. UML-Digramme werden bei mir nicht nochmal angefasst. Ich behaupte einfach mal ein gut geplantes Projekt benötigt kein UML-Refresh.
Archiv
Dieses Thema wurde archiviert und kann nicht mehr beantwortet werden.