Geometrische Objekte in Liste speichern

[Informatik-LK]

Hallo ihr!

Ich wollte mal fragen, wie man die Eigenschaften eines Dreiecks, eines Rechtecks und die eines Kreises in einer Liste vom Typ TList speichern kann.
Mit Eigenschaften meine ich hierbei:

- beim Dreieck 3 Punkte: TPoint
- beim Rechteck 2 Punkte: TPoint
- beim Kreis 1 Punkt: TPoint und Radius: Integer.

Ich hoffe, ihr könnt mir helfen.

Informatik-LK

[Sir Rufo]

Erzeuge Dir 3 Klassen für jeden Typ halt eine und schmeiß die in die Liste ... fertig.

TList speichert alles was von TObject abgeleitet wurde und das ist jede Klasse ;)

[edit]
ok, weil du Delphi-Anfänger bist :mrgreen:

Delphi-Quellcode:

type
  TRechteck = class
    Punkt1 : TPoint;
    Punkt2 : TPoint;
  end;

Und so greifst du über die Liste darauf zu:

Delphi-Quellcode:

if 
  Liste.Items[ i ] is TRechteck
then
  begin
    with 
      TRechteck( Liste.Items[ i ] )
    do
      begin
        // Hier kannst du auf das Objekt zugreifen
        // z.B.
        Punkt1.X := 10;
      end;
  end;

Die anderen Klassen werden analog behandelt.
[/edit]

[Die Muhkuh]

Anstatt die TList nimmst eine TObjectList, die kümmert sich gleich noch um das Freigeben der Objekte.

[Cyf]

Ich seh hier irgenwie grad den Grund nicht, Objekte statt Records zu verwenden. Würden die es nicht auch tun? :gruebel:

[WS1976]

Hallo,

für jeden Typ eine Klasse? Viel zu umständlich.
ich würde eine Klasse nutzen in der es ein Array of Tpoint gibt. Zusätzlich definierst du dir einen Aufzählungstyp sodass du nachher fesstellen kannst was in der Klasse gespeichert wurde.
Willst du z.B. zusätzlich eine Zeichenroutine einfügen kannst du das mit canvas.polygon (weiss nicht exakt wie die procedure heisst) machen.

Delphi-Quellcode:

   Ageotyp=(Dreieck,Viereck,Kreis);
   Tgeometrie=class
      punkte:array of Tpoint;
      parameter:array of integer;  //Radius für Kreis, 2 Radien für Ellipse
      geotyp:Ageotyp; //Ageotyp musst du als Aufzählungstyp definieren Ageotyp=(Dreieck,Viereck,Kreis)

      Constructor, Destructor, Prozeduren......
   end;

Beide Arrays sind offen, das heisst du musst, bevor du sie nutzen kannst die Grösse festlegen.
Als Beispiel für die Definition eines Kreises(habs nicht ausprobiert, also nicht böse sein wenn Fehler drin sind):

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var a:Tgeometrie;
begin
  a.Create;
  a.geotyp:=Kreis;
  setlength(a.punkte,1);
  setlength(a.parameter,1);
  a.punkte[0].X:=100; //Mittelpunkt X Wert
  a.punkte[0].Y:=100; //Mittelpunkt Y Wert
  a.parameter[0]:=50; //Radius
end;

Versuchs einfach mal, solltest du nicht zurecht kommen kannst du ja deinen Code posten.

Ich hoffe dir ist damit geholfen.

Grüsse
Rainer

[alzaimar]

Zitat:

Zitat von Cyf

Ich seh hier irgenwie grad den Grund nicht, Objekte statt Records zu verwenden. Würden die es nicht auch tun? :gruebel:

Ja, aber wir leben in OOP-Zeiten, da nimmt man eben Klassen. Im Endeffekt müsstest Du ja Record-Zeiger in der Liste speichen, sodaß die Implementierung wieder etwas umständlicher wird.

Zitat:

Zitat von WS1976

für jeden Typ eine Klasse? Viel zu umständlich. ich würde eine Klasse nutzen in der es ein Array of Tpoint gibt.

Du pervertierst den OOP-Gedanken, indem Du eine Gottklasse definierst, die alles macht. So soll es ja gerade nicht sein.

Man könnte sich eine Basisklasse definieren, die grundlegende Funktionalität bereitstellt, z.B. 'Zeichnen', 'Umriss', 'MausInObjekt' usw. Die Methoden werden in den konkreten abgeleiteten Klassen implementiert, aber man kann einfach alle Objekte Zeichnen:

Delphi-Quellcode:

For i:=0 to GeoListe.Count - 1 do
  TGeoObjekt(GeoListe[i]).ZeichneObjekt;

Darauf aufbauend könnte man dann ein komplexes TGeoObjekt definieren, das aus einzelnen TGeoObjekten besteht und so eine recht komplexe und mächte Klassenbibliothek aufbauen.

[Sir Rufo]

Ja, diese Vererbung ist genau der Grund für die Klassen.

Da aber Informatik-LK in seiner Signatur "Ich bin ein absoluter Delphi-Anfänger." stehen hat, wollte ich ihm aber nicht sofort mit der Vererbung kommen, aber schon mal auf das richtige Pferd setzen ;)

[alzaimar]

Dein Beitrag war ja auch ok: Eine gute Mischung aus OOP und einfacher Umsetzung.

[SirThornberry]

eine recht einfache Lösung wären variant-records. Gibt es eigentlich auch Variant-Objects? :gruebel:

[Sir Rufo]

Zitat:

Zitat von SirThornberry

eine recht einfache Lösung wären variant-records. Gibt es eigentlich auch Variant-Objects? :gruebel:

Na klar, indem du die Variablen/Properties als Variant deklarierst.

Aber die Umsetzung ist nur im ersten Antritt einfacher. Wenn du da etwas mehr machen möchtest (Berechnung Flächeninhalt, Umfang, Zeichnen, etc.) dann bist du mit OOP besser dran und vor allem übersichtlicher!
Auch die Erweiterung um andere geometrische Objekte ist dann nur noch ein Spaziergang ;)

cu

Oliver

[SirThornberry]

Zitat:

Na klar, indem du die Variablen/Properties als Variant deklarierst.

Ich meinte im gleichen Stile wie Variant-Records (nicht durch Verwendung des Typen Variant)

[WS1976]

Hallo alzaimar,

Zitat:

WS1976 hat folgendes geschrieben:
für jeden Typ eine Klasse? Viel zu umständlich. ich würde eine Klasse nutzen in der es ein Array of Tpoint gibt.

Deine Antwort:

Zitat:

Du pervertierst den OOP-Gedanken, indem Du eine Gottklasse definierst, die alles macht. So soll es ja gerade nicht sein.

Das sehe ich nicht so! Gerade die Vererbarkeit und damit die Erweiterbarkeit der Klasse ist doch entscheidend.
Was soll ich denn mit einer Basisklasse für jede geometrische Form?
Soll ich jedesmal wenn ich eine neue geometrische Form hinzufügen will eine neue Klasse erfinden?
Entschuldige aber da hast entweder du oder ich OOP nicht richtig verstanden!

Grüsse
Rainer

[quendolineDD]

Dann müsste man aber in dem Konzept TViereck wieder als Basisklasse nehmen, abgeleitet von TGeoObjekt. Und dann von TViereck TRhombus, TTrapez etc. ableiten.
Wäre sicherlich sehr hart am OOP-Gedanken gemacht, aber irgendwie finde ich das wiederum unsinnig. Da könnte man doch eine Gottklasse TViereck machen mit einem TViereckTyp und dann jeweils vom Typen her die Berechnung machen. Wäre zumindest vermindeter Programmieraufwand ...

[WS1976]

Hallo,
was spricht denn dagegen eine Basisklasse mit einigen geometrischen Figuren zu nutzen.
Braucht man irgendetwas zusätzlich leitet man eine Klasse davon ab und bringt die zusätzlich benötigten Elemente ein.
Ich finds nur blöd für jedes einzelne Element eine eigene Klasse zu schreiben.
Mir geht einfach nicht ein was das für einen Sinn haben soll. (Zumal bei so einer einfachen Klasse)
Dies hat auch nichts mit OOP zu tun sondern ist nur unnötige Arbeit.
Grüsse
Rainer

[quendolineDD]

Es hat sehr wohl etwas mit OOP zu tun. Wenn man sich strikt daran hält, dann hat man eine Basisklasse, die bestimmte Methoden und Eigenschaften bereitstellt und wiederum an ihre Nachkommen weitervererbt. Die Nachkommen spezifizieren oder erweitern diese Methoden und Eigenschaften oder übernehmen diese einfach.

Es ist hier deutlich sichtbar, das in diesem Fall die Hierachie nach zB Vierecke nochmal in ihre Sonderformen unterschieden werden müssen und die unterschiedlichen Berechnungen für einige Werte angepasst werden müssen. So wirklich "viel" Arbeit ist das nicht.

Für die Frage des TE:

Schreibe dir jeweils ein Simples Klassenmodell aus einer Basisklasse und deinen 3 darauf abgeleiteten Kinderklassen. Diese kannst du dann in einer Objectlist speichern um so diese einfach in einer Liste zu verwalten.

Lg