OOP Frage bei Spiel

[DeerHunter]

Ich versuche gerade mich ein wenig in OOP zu üben, wozu ich ein kleines Strategiespielchen schreiben wollte. Momentan steh ich vor einem allgemeinen Problem, was den Aufbau des Objektmodells betrifft...

Es gibt Einheiten und Ressourcen auf der Karte, die ich beide jeweils als Klassen definitiert habe, TEinheit und TRessource. Diese sind direkt von TObject abgeleitet, haben also nichts miteinander zu tun.
Ich möchte nun, dass, je nachdem, was der Benutzer gerade angeklickt hat (z.b. eine Einheit), im Infofenster Informationen über dieses etwas stehn. Wenn es eine Einheit ist halt die Werte der Einheit, bei einer Ressource (die man ja auch anklicken können soll) eben wieviel sich noch in diesem Ressourcenfeld befindet.

Die Auswahl habe ich nun in einer TList organisiert, da man bei Einheiten ja durchaus auch mehrere gleichzeitig selektieren kann.
Ich habe also die Pointer auf die Objekte, die gerade markiert sind. Bisher habe ich (als ich nur die Einheiten implementiert hatte) dann so darauf zugegriffen: TEinheit(Liste.Items[i])
Aber es könnte ja auch eine Ressource sein, also gibt es irgendwie eine Möglichkeit, herauszufinden, ob das jeweilige Objekt, auf das der Pointer zeigt, nun vom Typ TEinheit oder TRessource ist?

Oder hat jemand einen Tipp, wie ich das ganze geschickter lösen kann? Natürlich könnte ich verschiedene Listen führen, je nachdem, was gerade für Items selektiert sind.. aber das wäre doch irgendwo unschön und umständlich oder?
Mit OOP Sachen habe ich leider noch nicht so die Erfahrungen, deswegen ist mir völlig fremd, wie man hier am besten vorgeht.

[dizzy]

Die RTTI ist dein Freund; schau dir mal den is und den as -Operator an.

\\edit: Hatte die Tags vermurkst...

[DeerHunter]

Ah stimmt, das kommt mir doch bekannt vor

if TObject(Liste.Items[i]) is TEinheit then ... so läuft der Spaß

Danke! damit wär das geklärt

[Nonsense]

Btw: Wenn du Dich in OOP übst, solltest du TEinheit und TResource nicht von TObject ableiten. Es gibt doch sicherlich viele Geimeinsamkeiten, die man in eine Oberklasse zusammenfügen könnte, oder?

[dizzy]

Zitat von DeerHunter:

if TObject(Liste.Items[i]) is TEinheit then ...

Den Cast nach TObject kann man imho hier auch sparen - bin mir nicht 100%ig sicher, aber müsste...
Ansonsten ist das genau was ich meinte .

Gruss,
Fabian

[DeerHunter]

Zitat von Nonsense:

Btw: Wenn du Dich in OOP übst, solltest du TEinheit und TResource nicht von TObject ableiten. Es gibt doch sicherlich viele Geimeinsamkeiten, die man in eine Oberklasse zusammenfügen könnte, oder?

ja stimmt schon, habe ich jetzt auch noch gemacht, danke für den tipp

Zitat von dizzy:

Den Cast nach TObject kann man imho hier auch sparen - bin mir nicht 100%ig sicher, aber müsste...

naja, genau daran bin ich anfangs gescheitert.. ohne den Cast ging es nämlich nicht...

[Muetze1]

Moin!

Könnte er sich sparen, wenn die Liste z.B. eine TObjectList wäre. Eine TList gibt nur Pointer zurück und die muss man erstmal typecasten auf ein Objekt bevor man damit irgendwelche Is Abfragen machen kann.

MfG
Muetze1

[DeerHunter]

Hallo Muetze,
leider war mir TObjectList nicht bekannt.. deswegen hab ich's bisher mit den normalen Lists gemacht... aber wenn es da natürlich soetwas praktisches schon gibt, dann werd ich wohl das ganze mal umändern

[dizzy]

Hmmmm, man merkt dass ich meine Listen meist für den speziellen Fall selber schreibe und nur selten auf TList zurückgreife . Den Unterschied kannte ich so auch noch nicht.

[choose]

Zitat von DeerHunter:

Ich versuche gerade mich ein wenig in OOP zu üben

Hallo DeerHunter,

wenn Du Dich wirklich in OOP üben willst, solltest Du vor allem versuchen, ohne Unterscheidungen der Typen Deine Funktionalität abzubilden. Also keine Kunstrukte der Art:

Delphi-Quellcode:

case myObject.ClassType of
  TMyClass1: DoSth;
  TMyClass2: DoSthElse;
  ...

zu verwenden (zumal dies in Delphi ohnehin nicht ohne weiteres mit einem case möglich ist), sondern Delegation und Vererbung ausnutzen.
Möchtest Du bspw. einen unterschiedlichen Text in Abhängigkeit der Klasse ausgeben, könnte eine Lösung so aussehen:

Delphi-Quellcode:

type
  TMyBaseClass = class
  public
    function GetText: string; virtual; abstract;
  end;
  
  TMyClassA = class(TMyBaseClass)
  public  
    function GetText: string; override;
  end;
  
  TMyClassB = class(TMyBaseClass)
  public
    function GetText: string; override;
  end;

Deine Liste erwartet dann lediglich Exemplar der Klasse TMyBaseClass und führt die Operation GetText aus.

Verfolgt man diesen Ansatz konsequent (zB für das Zeichnen, Laden, Speichern, Bewegen, etc.), kann der Klient (der Programmteil, der mit heterogenen Klassen arbeitet) zwar von der konkreten Klasse abstrahieren, jedoch überfrachtest Du entweder Deine Klassen mit zu vielen Methoden und schaffst eine Art "ich kann alles"-Klasse, die wohl schwer zu beherrschen sein wird (typisch für Delphi-Programme ) , oder Du machst Dich zu sehr von einer strikten Vererbungslinie abhängig.

Wenn Du an diesem Punkt angekommen sein solltest, lohnt sich ggf ein Blick in die Menge von Entwurfsmustern (hier: Besuchermuster/Visitor Pattern) oder der Einsatz von Interfaces.

Viel Erfolg!