Setter mehrfach überschreiben.

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

[Dejan Vu]

Wieso schreibt man nicht einfach ein Werkzeug pro Figur? Dann fallen alle Fragen weg.
Ich hab ne TFigur.
Wenn ich sie zeichnen will, nehme ich einen TFigurPainter, bzw. ne abgeleitete Klasse, oder ne Klasse, die das IFigurPainter-Interface implementiert

Und wenn ich die TFigur speichern will, dann nehme ich ... einen TFigurWriter...
Und wenn ich die TFigur laden will, dann ...
Und wenn ich die TFigur drucken will, dann ...
Und wenn ich die TFigur backen will, dann ...

usw. usw.
Daraus kann man dann sogar eine Factory-Factory bauen:

Delphi-Quellcode:

Procedure TuWasMitDerFigur (DieAktion : FigurAktion; Figur : TFigure);
Var
  Aktion : TFigurAktion;
  AktionFactory : TFigureAktionFactory;

Begin
  AktionFactory := TFigurAktionFactoryFactory.CreateFactory(DieAktion);
  Aktion := AktionFactory.Create(Figur);
  Aktion.FühreAus(Figur);
End;

Die TFigurAktionFactoryFactory liefert eine TFigurAktionFactory, je nach inhalt von 'DieAktion' (Laden,Speichern,Zeichnen,Drucken,Backen).

Und die AktionFactory liefert die ensprechende Aktionsklasse für die Figur.

Und die Aktion führt die Aktion aus :stupid:

Diesen Code musst Du nie wieder ändern. Du registrierst nur weitere Figuren, Aktionen und deklarierst neue FigurAktion('Tanzen' z.B. oder.. äh.. heiraten, keine Ahnung). D.h.: Du änderst den Code nie wieder (OCP).

[Bjoerk]

Du machst mir echt Laune. Wirfst mal so eben die Arbeit von ca. 2 Jahren weg.:) Wenn man ein Figur Line, dann hat man auch ein schnell einen Pfeil oder einen Hint. Wenn man einen Kreis hat dann auch schnell eine Ellipse, einen Arc, eine Kreislinie ect. Das Zusammenfassen ist in schon in Ordnung so (Siehe auch TShape). Das eigentliche Zeichen wird oft auch weiter delegiert. Darum sollte es hier aber nicht gehen. Das override von Methoden ist nicht das Problem hier. Schau dir mal den letzten Post von DeddyH an. Genauso bräuchte ich das auch für möglichst viele Props. Daran habe ich aber beim Design nicht gedacht. Zur Zeit überlege ich, analog den Werkzeugklassen Datenklassen zu erstellen, damit gings vermutlich auch.

[Bjoerk]

Zitat:

Zitat von stahli (Beitrag 1304803)

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

[Dejan Vu]

Zitat:

Zitat von Bjoerk (Beitrag 1304825)

Wenn man ein Figur Line, dann hat man auch ein schnell einen Pfeil oder einen Hint. Wenn man einen Kreis hat dann auch schnell eine Ellipse, einen Arc, eine Kreislinie ect.

Also das widerspricht ja nicht meinem Ansatz. Die Figuren können voneinander abgeleitet sein (Achtung! Square/Rectangle-Problematik), aber ein Painter macht eben genau eine einzige Sache. Ein Pfeil-Painter kann ja einen Linien-Painter verwenden, aber er muss nicht unbedingt von ihm ableiten. Nebenbei: Ein Pfeil ist ja auch nicht unbedingt eine Linie.

Auf diese Weise bleiben die Klassen klein. Und Du hast kein Ableitungskuddelmuddel. Denn das hast Du, sonst würdest Du die Frage hier nicht stellen.

Diese Ableitungsmanie ist ein Irrweg, wenn Du mich fragst. Interfaces, Algorithms und Delegates sind ein anderer Weg, gemeinsames Verhalten zu ordnen. So könnten deine Painter komplett unabhängig voneinander sein und nur das IShapePainter-Interface implementieren.

[Bjoerk]

Du hast mich immer noch nicht verstanden. Was machst du, wenn du ein rundes Control hast, aber TCustomControl keine Radius Prop hat, dein Objectinspector aber ein TCustomControl erwartet? Entweder du kastet dich im OI zu tode oder du führst eben abtsracte Getter und Setter schon auf dieser Ebene ein. Oder du machst es wie DeddyH vorgeschlagen hat über eine allgemeine (hier) AddFloat und überschreibst die. Eine Ableitungsmanie kann ich darin nicht erkennen..

[stahli]

Eine Überlegung dazu:

Wenn das Problem EIGENTLICH der Objektinspektor ist, dann musst Du den verbessern oder umbauen.
Der OI darf einfach nicht nur ein CustomControl erwarten, sondern er muss mit allen möglichen Klassen klar kommen.

Grundsätzlich kann man ja alle Propertys einer Klasse ermitteln und im OI genau diese Propertys binden. Mit der neuen RTTI ab D2010 wüsste ich, wie das geht - mit D2007 nicht auf Anhieb.

Wenn das zu komplex oder nicht zielführend/ausreichend ist, kannst Du pro Klasse auch eine Property-Tabelle ablegen (z.B. als XML).
Da kannst Du für TRoundTool hinterlegen, dass der Radius gebunden werden soll und zwar mit 3 Nachkommastellen.
Wenn der OI einen Apfel binden soll, dann steht in der XML, dass er den Zuckergehalt binden soll.

So könntest Du das Problem m.E. geschickt auslagern ohne Deine Klassen zu sehr zu verbiegen.

Die Klassen könnten sich darauf beschränken, was sie selbst brauchen und müssen sich nicht noch um die Umgebung kümmern.

[himitsu]

Der OI nur geht auf Published-Property und die können auch über die "alte" RTTI ermittelt werden.