AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Anregung für Klassendesign

Ein Thema von Jumpy · begonnen am 26. Sep 2014 · letzter Beitrag vom 26. Sep 2014
 
Dejan Vu
(Gast)

n/a Beiträge
 
#3

AW: Anregung für Klassendesign

  Alt 26. Sep 2014, 12:02
Echt? Muss nicht. Ein Feld ist ein Feld und hat Nachbarn. Ein quadratisches Feld hat 4, ein hexagonales Feld eben 6. Aber es ist ein Feld. Dieses Model kann man später auf 5-dimensionale Hyperräume erweitern. Es bleibt dabei. Ein Feld ist ein Feld und ich kann von einem Feld auf bestimmte andere hüpfen.

Zur Frage:
Ich würde deine Klassen, Eigenschaften und Methoden erst einmal in Objectpascal aufschreiben, denn deine Beschreibung kannst Du 1:1 auf deine Klassen anwenden. Die genauen Eigenschaften sind zwar nicht bekannt, aber die Methoden ('Darf ich? Wo könnte ich hin?' etc) schon. Und damit sind auch die Abhängigkeiten grob skizziert, denn für eine bestimmte Entscheidung oder Aufgabe benötigt eine Figur das Wissen um 'Felder' und vielleicht sogar auch 'Objekte'.

Durch die Abhängigkeiten muss z.B. ein Objekt auch 'Felder' kennen, denn es muss ja wissen, ob es da rauf darf.
Wenn Du die groben Abhängigkeiten umgesetzt hast, schaust Du dir jede Klasse an. Wenn z.B. eine Figur -neben der schönen Aufgabe, eine Figur zu sein- noch andere Aufgaben hat (z.B. 'Darf ich auf dieses Feld?') dann schreibst Du dir eine Klasse, die diese Entscheidung fällt, also einen 'TFigurLocator' oder so. Damit hat die Figur diese Aufgabe delegiert. Da sich Objekte und Figuren bezüglich diverser Entscheidungen nicht unterscheiden, können sie eine gemeinsame Basisklasse haben, müssen aber nicht: Bloß weil ein Tisch und ein Pferd jeweils 4 Beine haben, sollte man keine Basisklasse hierfür erstellen. Die Gemeinsamkeit könnte sich auch über ein Interface und eben die 'TXXXXLocator'-Entscheiderklassen abbilden lassen.

Ich würde 'einfach mal anfangen' und hier den Ansatz posten. Wirst schon sehen, wie gut die Ratschläge sind...

Crossreferences solltest Du vermeiden, z.B. durch oben skizzierte Delegierung an eine separate Klasse:
a <-> b => a -> c <- b
Anstatt : 'a kennt b und umgekehrt' (was eine zirkuläre Referenz ist)
macht man: 'a kennt c und b kennt c, c kennt a und b. Aber a und b kennen sich nicht mehr'.

Mit Sicherheit gibt es noch andere Wege zum Ziel, aber ich würde es so machen bzw. so erst einmal anfangen.

Geändert von Dejan Vu (26. Sep 2014 um 12:08 Uhr)
  Mit Zitat antworten Zitat
 

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:59 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz