Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Klassenbeziehungen planen und umsetzen
Gepro
myCSharp.de - Member



Dabei seit:
Beiträge: 419
Herkunft: NRW

Themenstarter:

Klassenbeziehungen planen und umsetzen

beantworten | zitieren | melden

Moin,
eine Frage, die mir schon die ganze Zeit auf der Seele liegt.
Wenn ich ein Klassendiagramm anlege und Beziehungen der einzelnen Klassen untereinander mit Kompositionen, Aggregationen und Assoziationen plane, stellt sich mir auch die Frage, wie ich diese später programmiertechnisch umsetze.

Gibt es "Richtlinien" wie man diese Benziehungen später umsetzt ?

Z.B.
Kompositionen:
Ich habe eine Klasse FootballClub und eine Klasse Stadium,
Hier habe ich eine Ganz-Teil Beziehung, Club ist Ganz und Stadium Teil und in diesem Fall eine Komposition; Wenn der Club weg ist, also nicht mehr existiert, dann existiert Stadium quasi auch nicht mehr.
-> Stadium ist eine Eigenschaft von Club und diese Referenz taucht nur in diesem Club auf

Aggregationen:
Wenn ich jetzt eine Klasse FootballClub und FootballPlayer habe, liegt auch hier eine Ganz-Teil Beziehung vor. Nur keine Komposition. Wenn der Club sich auflöst oder der Spieler wechselt, kann er immernoch bei einem anderen Club spielen oder sogar in der Nationalmanschaft.
-> Player sind als Liste eine Eigenschaft von Club, können aber in mehreren Objekten bzw. Klassen vorkommen

Assoziationen:
Ich habe eine Klasse Transfermarket und FootballPlayer, auf dem Transfermarkt befinden sich kurzfirstig die Player. Diese Player werden vllt. per Methode als Parameter übergeben, sind aber keine Eigenschaft von Transfermarket
-> Vllt. Methode: Transfermarket.DoTransfer(FootballPlayer playerIn);


Werden diese Beziehungensarten programmiertechisch so umgesetzt wie ich es bei den Pfeilen geschildert habe ? Oder wie plane ich diese Beziehungen und was bringen sie mir für die Programmierung, wenn es dort keine "Beziehungs-Implementierungs-Richtlinien" gibt??
private Nachricht | Beiträge des Benutzers
bigeddie
myCSharp.de - Member



Dabei seit:
Beiträge: 369
Herkunft: Mannheim

beantworten | zitieren | melden

Hallo Gepro,

einige kleine Bemerkungen:

zur Aggregation und Komposition:
Fasse die Spieler doch besser in einem Team zusammen und lass dann das Team ein Teil der Clubs sein.
Team ist ein Teil des Clubs also Komposition, da die Existenz des Teams(Teil) durch die Existenz des Clubs (Ganzes) bedingt ist. "Zerfällt" der Club, zerfällt auch das Team. Die Spieler des Teams sind zwar transitiv betrachtet auch ein Teil des Clubs, existieren jedoch selbst nach der Auflösung des Clubs weiter.

Eine Assiziation ist meines beschränkten wissens nach doch eigentlich be Beschreibung einer Beziehung zwischen zwei oder mehr Objekten, also Spieler1(Objekt) ist Mitglied in(Assoziation) Team(Objekt z.B. List<Spieler>).

Hoffe das hat dir etwas geholfen.

Grüße

Jürgen
Man muß nichts wissen,
man muß nur wissen wer es wissen könnte
oder wo es steht;-)
private Nachricht | Beiträge des Benutzers
Gepro
myCSharp.de - Member



Dabei seit:
Beiträge: 419
Herkunft: NRW

Themenstarter:

beantworten | zitieren | melden

Zitat
Spieler1(Objekt) ist Mitglied in(Assoziation) Team(Objekt z.B. List<Spieler>).
Würde man hier nicht sagen, dass Spieler ein und Team als Beziehung eine Aggregation haben ?
Spieler:Teil, Team:Ganz ?


Das mit den Spielern war ja auch ein Beispiel: Meine Hauptfrage ist ja, ob es bestimmte "Implementier-Richtlinien" gibt, für die jweiligen Beziehungsarten, um einfacher dieses Klassendiagramm umsetzen zu können
private Nachricht | Beiträge des Benutzers
bigeddie
myCSharp.de - Member



Dabei seit:
Beiträge: 369
Herkunft: Mannheim

beantworten | zitieren | melden

Hallo Gepro,

also wenn Du näheres zum Thema SWT wissen willst, dann solltest Du dir diesen Link antun.
Die Bücher von Herrn Balzert sind am anfang vielleicht etwas schwer verständlich, aber können dir bei deiner Frage bestimmt weiterhelfen.

Regeln im Sinne von "wenn Du das hast, dann mache das" sind mir nicht bekannt, aber die Beschreibung der von dir in deinem Ur-Post angeführten Begriffe findest Du auch bei Wiki. Programmierbeispiele (zwar in Java, aber gut verständlich)http://www.pst.informatik.uni-muenchen.de/lehre/WS0304/infoeinf/materialien/folien/Folien07Assoz6.pdf

Grüße

Jürgen
Man muß nichts wissen,
man muß nur wissen wer es wissen könnte
oder wo es steht;-)
private Nachricht | Beiträge des Benutzers
Corpsegrinder
myCSharp.de - Member



Dabei seit:
Beiträge: 401

beantworten | zitieren | melden

Zitat von Gepro
Kompositionen:
Ich habe eine Klasse FootballClub und eine Klasse Stadium,
Hier habe ich eine Ganz-Teil Beziehung, Club ist Ganz und Stadium Teil und in diesem Fall eine Komposition; Wenn der Club weg ist, also nicht mehr existiert, dann existiert Stadium quasi auch nicht mehr.
-> Stadium ist eine Eigenschaft von Club und diese Referenz taucht nur in diesem Club auf

Würde ich anders sehen... Ein Stadion fällt ja nicht in sich zusammen, nur weil es den Club nicht mehr gibt. Außerdem gibt es auch Stadien, die nicht nur von einem Club bzw. einer Sportart bespielt werden. Z.B. wurde erst das Olympiastadion und jetzt die Allianz Arena sowohl vom FC Bayern München, als auch vom TSV 1860 München bespielt. Ich würde Stadion zu Club eher in eine 1 zu n Beziehung stellen, da jeder Club in einem Heimstadion spielt, aber in einem Heimstadion mehrere Clubs spielen können und sowohl Stadion, als auch Club unabhängig voneinander existieren können.
private Nachricht | Beiträge des Benutzers
Th69
myCSharp.de - Experte

Avatar #avatar-2578.jpg


Dabei seit:
Beiträge: 4.177

beantworten | zitieren | melden

Hallo zusammen,

ich sehe es auch so wie Corpsegrinder, also das die einzelnen Objekte per Aggregation zusammenhängen (also selbständig existieren und austauschbar sind).
Einzig (wie schon angesprochen) das oder die Teams (falls auch die 2. Mannschaft und evtl. Jugend-Mannschaft verwaltet werden sollen) sind eine Komposition des Vereins (Clubs).

In C# gibt es jedoch technisch gesehen keinen Unterschied zwischen Aggregation und Komposition (nicht so wie in C bzw. C++, wo es echte Member und Zeiger bzw. Referenzmember gibt).
Wichtiger ist jeweils zu entscheiden, ob es eine strikte 1:1 oder eine 1:N Beziehung zwischen den einzelnen Klassen bzw. Objekten gibt.

Edit: bzw. ob auch Null-Referenzen erlaubt sein sollen (z.B. das ein Spieler z.Z. vereinslos ist).
private Nachricht | Beiträge des Benutzers
Gepro
myCSharp.de - Member



Dabei seit:
Beiträge: 419
Herkunft: NRW

Themenstarter:

beantworten | zitieren | melden

Nochmal auf das Thema zurück zu kommen,
Ich habe eine Komposition, z.B. FootballClub (Ganz) und Stadium (Teil) <-- gehen wir jetzt mal davon aus, das hier die Komposition definitiv richtig wär
Wenn ich jetzt eine Referenz vom Stadium in die FootballClub Klasse aufbewahren möchte, darf dies nicht als Eigenschaft geschehen oder ?
Wenn Stadium eine Eigenschaft und somit öffentlich von FootballClub wär, könnte man von außen darauf referenzieren und somit, wenn das Objekt
von FootballClub gelöscht wird, hätte man noch eine Referenz vom Stadium über (und bei der Komposition ist ein "Teil" vom Lebenszyclus des "Ganzen" abhängig)
Wenn man allerdings von Außen Informationen vom Stadium erhalten möchte, müsste man ja, wenn die Stadium nicht als Eigenschaft festgelegt wird, sondern nur als private Variable,
ganz viele Getter Methoden schreiben, die alle Möglichen und wichtigen Informationen bzw. Eigenschaften von Stadium aus dem FootballClub Objekt zurückgeben,
das kanns doch auch nicht sein... ??

und 2. gibts einen programmiertechnischen Unterschied zwischen Aggregationen und Assoziationen ?? Wie z.B. bei meiner Kompositionen von der Art her?
private Nachricht | Beiträge des Benutzers
Th69
myCSharp.de - Experte

Avatar #avatar-2578.jpg


Dabei seit:
Beiträge: 4.177

beantworten | zitieren | melden

Das Stichwort dazu lautet: Interface

Du definierst dir dann ein Interface (z.B. IStadium), bei dem du nur die Getter definierst. Intern in der Vereinsklasse benutzt du dann aber ein Objekt der Klasse Stadium, welches selber IStadium implementiert (auch wenn ich immer noch finde, daß ein Stadium keine Bestandteil eines Vereins ist -)


interface IStadium
{
  string Name { get; }
  int Capacity { get; }
}

class Stadium : IStadium
{
  public string Name { get; set }
  public int Capacity { get; set }

  public void EnlargeStadium()
  {
     Capacity *= 2; // -)
  }
}

class Club
{
  public IStadium // <- wichtig: hier das Interface
  {
     return stadium;
  }

   private Stadium stadium;

   // in den Klassenmethoden kannst du dann auf 'stadium' zugreifen,
   // d.h. auch Änderungen vornehmen
}
So kann von außen nur auf die Interface-Member des Stadiums zugegriffen werden (z.B. nur Getter).

P.S. Erst der GC entscheidet, ob auch wirklich die Referenz auf das Stadium-Objekt nicht mehr benötigt wird (darauf hast und solltest du keinen Einfluß darauf nehmen).
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Th69 am .
private Nachricht | Beiträge des Benutzers
Gepro
myCSharp.de - Member



Dabei seit:
Beiträge: 419
Herkunft: NRW

Themenstarter:

beantworten | zitieren | melden

Aha, danke, das ergibt Sinn;)

Allgemein gibt es keine Regel oder Richtlinie, die besagt, wie Kompositionen implementiert werden ?
Aber diese Schreibweise find ich sehr gut, mit den Schnittstellen.

Natürlich möchte ich auch noch gerne die 2. Frage beantwortet haben, aber mir kommt schon wieder eine neue in den Sinn:
Ich habe FootballClub und Player, ist Player "Teil" vom "Ganzen" FootballClub ?? Ein Verein kann ja ohne Fußballspieler eigendlich nicht "existieren", also Aggregation oder Assotiation ?

@edit:
Wobei, es ist immer noch möglich auf das Stadium Objekt zuzugreifen:


    public class EntityBase
    {
        public string Name { get; set; }
    }

    public interface IStadium
    {
        string Name { get;}
        int Capacity { get; }
    }

    public class Stadium : EntityBase, IStadium
    {
        public Stadium()
        {
            this.Name = "Stadion1";
            this.Capacity = 50000;
            this.Terraces = 30000;
            this.Seats = 20000;
        }

        public int Terraces { get; set; }

        public int Seats { get; set; }

        #region IStadium Members

        public int Capacity { get; set; }

        #endregion
    }

    public class Club : EntityBase
    {
        private Stadium stadium;

        public Club()
        {
            this.Name = "";
            this.stadium = new Stadium();
            this.Established = DateTime.Today;
        }

        public DateTime Established { get; set; }

        public IStadium Stadium
        {
            get { return this.stadium; }
        }

    }

public void DoTest()
{
            Club club = new Club();
            IStadium stadiumData = club.Stadium;
            club = null; // <- Ab hier, dürfte auch eig. kein Stadium Zugriff mehr Möglich sein

            Stadium cs = (Stadium)stadiumData; //<- da ist das Problem
            int terraces = cs.Terraces;
}
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Gepro am .
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 49.486
Herkunft: Berlin

beantworten | zitieren | melden

Hallo Gepro,
Zitat
auch wenn ich immer noch finde, daß ein Stadium keine Bestandteil eines Vereins ist -)
das stehe ich genauso. Das Stadium ist offensichtlich kein Teil des Vereins. Mehrere Vereine können sich ein Stadium teilen. Ein Verein muss kein (festes) Stadium haben. Stadiumsbetreiber und Verein müssen nicht identisch sein. Also keine Ganzes-Teil-Beziehung.
Zitat
Ich habe FootballClub und Player, ist Player "Teil" vom "Ganzen" FootballClub ?? Ein Verein kann ja ohne Fußballspieler eigendlich nicht "existieren", also Aggregation oder Assotiation ?
Bei Spielern ist es genau das gleiche: offensichtlich keine Ganzes-Teil-Beziehung.

UML unterscheidet außerdem zwischen drei Fällen: Komposition, Aggregation und Assoziation, wobei die Stärke der Beziehung in der angegebenen Reihenfolge immer schwächer wird. Die Übergänge sind aber m.E. fließend. Deshalb ist keine klare Abgrenzung möglich, meistens aber auch nicht nötig.

Nimm das klassische (Lehrbuch-)Beispiel für eine Ganze-Teil-Beziehung: Auto und Motor. Klar, das Auto braucht den Motor, um zu funktionieren. Ein Motor alleine kann nicht fahren. Der Motor ist fest mit dem Auto verbunden und am Ende landen sie gemeinsam in der Schrottpresse. Aber gilt das alles wirklich so absolut? Was ist wenn der Motor defekt ist und ausgetauscht wird? Oder wenn man ihn durch einen leistungsfähigeren ersetzen will? Kann man einen Automotor nicht auch ohne Auto sinnvoll nutzen, z.B. in einem Blockheizkraftwerk? Endet die Lebensdauer wirklich immer gleichzeitig oder wird der intakte Motor nicht evtl. vor dem Verschrotten ausgebaut?

Wichtig ist doch, dass die Klassen so implementiert sind, dass man ihre Objekte vernünftig benutzen kann, nicht dass irgendwelche Beziehungen stur und schematisch nach einer exakten (und nicht vorhandenen) Definition umgesetzt werden.

herbivore
private Nachricht | Beiträge des Benutzers
Gepro
myCSharp.de - Member



Dabei seit:
Beiträge: 419
Herkunft: NRW

Themenstarter:

beantworten | zitieren | melden

Ok, vielleicht habe ich das mit den Spielern falsch gesehen,
Warscheinlich ist Spieler nicht Teil vom Verein in Bezug auf eine Aggregation...
vielleicht muss ich es so sehen:
Klasse "Team" (Unter anderem kapselt es eine Liste mit Spielern) ist Teil vom Verein und muss eine Komposition sein, weil wenn es den Verein nicht mehr gibt, gibt es auch das Team als solches nicht mehr... Und Spieler ist dann Teil vom Team, aber nicht zu sehr abhängig vom Team und somit eine Aggregation...
Sehe ich das jetzt richtig ?
private Nachricht | Beiträge des Benutzers