Objekt-Beziehungen in C#-Code implementieren

[duke3368]

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!!!

[BugBite]

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

[TDM]

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

[BugBite]

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

[duke3368]

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?

[BugBite]

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!

[TDM]

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.

[BugBite]

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

[TDM]

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.