Laden...

Klassenbeziehungen planen und umsetzen

Erstellt von Gepro vor 13 Jahren Letzter Beitrag vor 13 Jahren 5.487 Views
G
Gepro Themenstarter:in
419 Beiträge seit 2007
vor 13 Jahren
Klassenbeziehungen planen und umsetzen

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

B
372 Beiträge seit 2007
vor 13 Jahren

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😉

G
Gepro Themenstarter:in
419 Beiträge seit 2007
vor 13 Jahren

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

B
372 Beiträge seit 2007
vor 13 Jahren

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😉

C
401 Beiträge seit 2007
vor 13 Jahren

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.

4.931 Beiträge seit 2008
vor 13 Jahren

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).

G
Gepro Themenstarter:in
419 Beiträge seit 2007
vor 13 Jahren

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?

4.931 Beiträge seit 2008
vor 13 Jahren

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).

G
Gepro Themenstarter:in
419 Beiträge seit 2007
vor 13 Jahren

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;
}

49.485 Beiträge seit 2005
vor 13 Jahren

Hallo Gepro,

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.

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

G
Gepro Themenstarter:in
419 Beiträge seit 2007
vor 13 Jahren

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 ?