Setter mehrfach überschreiben.

[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

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.

[Dejan Vu]

Zitat von Bjoerk:

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.

[Dejan Vu]

Zitat von 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?

Wieso sollte der OI ein TCustomControl erwarten? Verstehe ich nicht. Der OI erwartet ein Objekt, geht per RTTI die Eigenschaften durch und erstellt für jede published Property einen Editor. Dem ist doch wurscht, was Du ihm gibst.

Der OI kann auch ein TCustomControl erwarten (was blöd wäre, weil er dann kein Object-Inspector wäre, sondern ein CCI, ein 'CustomControl-Inspector'. Aber selbst wenn er das erwarten würde, ermittelt er zur Laufzeit per RTTI die Editoren/Zeilen, und zwar anhand des konkreten Typen des darzustellenden Objekts.

Zitat von Bjoerk:

Es ist nur so, daß die einzelnen Klassen, die davon abgeleitet sind, nicht jede Methode bzw. jede Property haben.

Genau das ist es, was dein Design 'falsch' macht. Deine Basisklasse soll nicht wissen, was eventuell einer ihrer Kinder für Eigenschaften haben könnte und einfach mal auf Verdacht eine abstrakte Eigenschaft einführen. Das ist kein OOP.

Zitat von Bjoerk:

Ok. Also: Ich habe 3 Klassen ala TShape (TWerkzeug1,2,3). Jede TWerkzeug Class kann so 15-25 Figuren zeichnen.

Imho falsch.

Zitat:

Der User wählt mit dem Speedbutton eines von ca. 70 zu zeichnenden Objecte aus. ... wenn Polygon -> dann TWerkzeug2 -> dann FWerkzeug2.Polygon.Add(X, Y).

Delphi-Quellcode:

Editor := TEditorFactory.Create(SelectedFigure); 
Editor.Add(X,Y);

Nehmen wir an, wir haben Figuren auf einem Tisch liegen, jede Figur hat eine Position:

Delphi-Quellcode:

For figure in FiguresOnTable do begin
  Painter := TPainterFactory.Create(figure.figure);
  Painter.Paint(figure.Location);
End;

Berechnung der Gesamtfläche

Delphi-Quellcode:

For figure in FiguresOnTable do begin
  SurfaceCalculator := TSurfaceCalculatorFactory.Create(figure.figure);
  TotalSurface := TotalSurface + SurfaceCalculator.Surface;
End;

Immer die selbe Soße.
Anstatt deine Klasse immer weiter aufzublähen (Anti-OCP), baust Du für jede Funktion eine neue Klassenfamilie. Natürlich kannst du für elementare Operationen eine Basisklasse nehmen, aber wenn Du Dich dabei ertappst, diese für neue Funktionen zu erweitern, verstößt Du gegen SRP und OCP. Das sollte ein Warnsignal sein, falls Du OOP-konform sein willst.

Zitat:

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

Mach mehr Klassen: 70 Figurtypen und 3 Klassen? Das kann nicht gehen, jedenfalls nicht mit OOD.

[Bjoerk]

Die Basisklasse gibt es nicht mehr (hatte ich doch schon geschrieben?). Und z.B. hier wünsch ich dir mit 70 Klassen viel Spaß:

Delphi-Quellcode:

procedure TGraphicObjectList.AddList(Value: TGraphicObjectList);
var
  I, Index: integer;
begin
  for I := 0 to Value.Count - 1 do
  begin
    if Value[I] is TGraphicObject1 then
      Index := Add(TGraphicObject1.Create)
    else
      if Value[I] is TGraphicObject2 then
        Index := Add(TGraphicObject2.Create)
      else
        Index := Add(TGraphicObject3.Create);
    Items[Index].Assign(Value[I]);
  end;
end;

procedure TGraphicObjectList.Assign(Value: TGraphicObjectList);
begin
  Clear;
  AddList(Value);
end;