Setter mehrfach überschreiben.

[DeddyH]

Den Sinn dieser Factory verstehe ich ehrlich gesagt nicht. Kommt noch eine Ableitung hinzu, muss auch die Factory geändert werden, damit sie die entsprechende Klasseninstanz liefern kann, das bringt irgendwie nix.

[Bjoerk]

Ei, ich hann gemennt..

[stahli]

Schreib doch mal, was Du da vor hast.
Willst Du nur eine Werkzeuginstanz?

Sollen das sichtbare Controls werden?

Was soll das Projekt machen und was die Fabrik?

[Bjoerk]

Ok. Also: Ich habe 3 Klassen ala TShape (TWerkzeug1,2,3). Jede TWerkzeug Class kann so 15-25 Figuren zeichnen. Alles was in den Shapes gleich ist, befindet sich in der Basisklasse TWerkzeug0. Der User wählt mit dem Speedbutton eines von ca. 70 zu zeichnenden Objecte aus. Je nachdem in welcher Klasse das Objekt gezeichnet wird, muß also Werkzeug1,2,3.Draw ausgeführt werden. Draw befindet sich abstract in TWerkzeug0 und wird von Werkzeug1,2,3 überschrieben. Ist somit kein Problem. Das ist aber bei den Variablen nicht so. Deshalb hatte ich die Idee mit der aufgeblähten Klasse von #9. Davon wäre TWerkzeug0 abgeleitet gewesen. Alle Properties (Getter/Setter) würden überschrieben. Zurzeit muß ich explizit auf 1 oder 2 oder 3 prüfen. Zum Beispiel: TWerkzeug2 hat eine Property Polygon, Werkzeug1 und Werkzeug3 nicht. Ich muß also prüfen,

wenn Polygon -> dann TWerkzeug2 -> dann FWerkzeug2.Polygon.Add(X, Y).

Dieses Prüfen ob 1 2 oder 3 ist aber nicht so prickelnd und sehr viel Tipparbeit (gewesen). Und was ist wenn es mal 4 oder 5 Werkzeugkategorien werden sollten (wurde ja schon angesprochen).

Ich hatte im Bezug auf dieses Programm schon mehrere Threads hier und da wurde mir immer (oder öfter) eine Faktory empfohlen. Anscheinend hab ich das noch nicht ausreichend kapiert bzw. den Sinn einer Faktory nicht ganz verstanden.

Ich suche eigentlich nur ein elegantes Handling für diese 3 Klassen.

[DeddyH]

Ohne die Klassen zu kennen: wäre es nicht möglich, eine Basis-Methode zu deklarieren (kann auch abstrakt sein) oder ersatzweise eine Property, die die abgeleiteten Klassen dann eben unterschiedlich behandeln? Statt also von außen Dings.Polygon.Add aufzurufen, wird eben der Weg über Basisklasse.AddPoint(X,Y) gegangen. AddPoint wird dabei unterschiedlich behandelt, aber eben nur intern, den Aufrufer schert das nicht.

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

[Bjoerk]

DeddyH, ich denke mal das wäre sicherlich möglich. Diese Idee hatte ich zum Beispiel noch nicht. Thanx.

[Bjoerk]

stahli, in Bezug auf gleiche Methoden hab ich das so. Mir geht's jetzt noch um die Properties. Da hat DeddyH ja einen Vorschlag gemacht. AddPoint könnte jede Klasse vertragen.