Setter mehrfach überschreiben.

[stahli]

Genau.

Was die Controls zeichnen geht von außen niemanden etwas an.
Ob sie intern ein Polygon verwalten oder mehrere Farben oder Textumbrüche ist normalerweise Privatsache der spezialisierten Klasse.

Nach außen musst Du ja nur das öffentlich machen, was die Umgebung Deiner Werkzeuge interessiert.

Du kannst Deine Basisklasse ja rel. klein halten:

Delphi-Quellcode:

TBaseClass = class
public
  procedure Paint; virtual;
end;

und in Deinen abgeleiteten Klassen führst Du private Detaileigenschaften ein:

Delphi-Quellcode:

TClassA = class(TBaseClass)
private
  Polygon...
public 
  procedure Paint; override;
end;

TClassB = class(TBaseClass)
private
  Text...
public 
  procedure Paint; override;
end;

Die Daten musst Du natürlich ggf. von außen klassenspezifisch zuweisen, aber die Basisklasse muss ja nicht alle Varianten kennen sondern nur die einheitlichen Eigenschaften.


Eine Factory wird Dir hier nichts bringen. Ich denke, Du musst die Klasseneigenschaften nur besser nach tatsächlichen Aufgaben trennen.

Müssen Deine Klassen noch etwas anderes machen, als sich zu zeichnen?

[Bjoerk]

Zitat von stahli:

[..] Müssen Deine Klassen noch etwas anderes machen, als sich zu zeichnen?

Ja, die Klassen machen mehr, viel mehr. Längenermittlung, Gewichtermittlung, Stücklisten, Schnittpunkte, Fangpunkte, diverse Rucksackprobleme lösen, OI, dxf/dwg Parser ect.. Das erledigen weitere Klassen in Verbindung mit dem Object und der Liste. Das Programm ist nicht ganz einfach, ehrlich gesagt bin ich froh daß ich’s überhaupt hingekriegt hab..

[stahli]

Dann hatte ich vermutlich eine Anwendung mit meiner Turniersoftware (siehe Homepage).
Ich hatte dazu Datenklassen und visuelle Controls voneinander getrennt.

Die Datenklassen haben die gesamte Logik und Daten gekapselt - also das eigentliche Projekt und den Turnierzustand abgebildet.

Die Controls konnten dann ein Datenobjekt referenzieren (TvSpieler z.B. einen TdSpieler).
So kann man gut unterscheiden, was jetzt für die Darstellung umgesetzt werden muss und was für die Datenverarbeitung.

Ein Framework hat dabei noch zusätzlich geholfen. Wenn z.B. ein TvControl doppelt geklickt oder evtl. Enter gedrückt wurde, dann hat das Framework untersucht, was dort für eine Datenklasse referenziert wird und welches Formular für diese Klasse zuständig ist und hat dieses (wenn eines gefunden wurde) gleich geöffnet und ein Databinding an die Controls durchgeführt.

Die Trennung von Daten und GUI kann ich UNBEDINGT empfehlen.
Wenn Du Dir dann noch etwas aufbaust, dass Dir bei der Datenbindung von der GUI an die Daten hilft (oder die GUI anhand der Datensituation aufbaut), dann sollte das eine sehr übersichtliche Arbeitsweise ergeben.

Natürlich macht das erst mal Arbeit, aber etwas fertiges liefert Delphi ja nicht mit.