Setter mehrfach überschreiben.

[stahli]

Er meint einen RT-OI. Ich weiß aber nicht, wie der genau umgesetzt ist.

[himitsu]

Zitat von stahli:

Er meint einen RT-OI. Ich weiß aber nicht, wie der genau umgesetzt ist.

Aso, aber vom "Verhalten" her doch bestimmt ähnlich dem IDE-OI.

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

[stahli]

Du musst das etwas strukturierter betrachten.

Basisklassen sind ja gut und nützlich. Aber sie müssen nur das wissen und können, was wirklich alle Ableitungen gemeinsam haben.

Wenn Du eine Objektkopie erzeugen willst, dann kann Deine Basisklasse z.B. folgende Methode haben.

Delphi-Quellcode:

TBaseClass = class
  function CreateCopy: TBaseClass; virtual;
end;

function TBaseClass.CreateCopy: TBaseClass;
begin
  Result := nil;
end;

und die Ableitungen spezifizieren das:

Delphi-Quellcode:

TClassA = class(TBaseClass)
  function CreateCopy: TBaseClass; override;
end;

function TClassA.CreateCopy: TBaseClass;
var
  A: TClassA;
begin
  A := TClassA.Create;
  A.Assigned(Self);
  // hier kann man auch noch beliebige andere (klassenspezifische) Dinge anstellen
  Result := A;
end;

So brauchst Du später nicht nach Klassen unterscheiden und rufst einfach NewItem := aItem.CreateCopy auf.

Mit Assign funktioniert das ja genau so.

Du musst also so viel wie möglich in Klassen kapseln und gemeinsame Eigenschaften so weit oben deklarieren wie notwendig.
Dann wird das von allein übersichtlicher.


Wenn man keine gemeinsame Basisklasse verwenden kann oder will, kann man auch Interfaces benutzen. Das hat Vor- und Nachteile, ist aber auf jeden Fall etwas komplexer.

[Bjoerk]

Ja doch. So hab ich‘s doch (Siehe z.B. Assign), anders wär’s ja ein Krampf? Aber um ein spezifisches Create kommst du nicht herum, sonst greift das override ja nicht.

[samso]

Zitat von Bjoerk:

Aber um ein spezifisches Create kommst du nicht herum, sonst greift das override ja nicht.

Der Klassentyp der Quellklasse ist doch bekannt. Also geht doch:

Delphi-Quellcode:

type
  TGraphicObjectClass = class of TGraphicObject;
procedure TGraphicObjectList.AddList(Value: TGraphicObjectList);
var
  I: integer;
  NewItem: TGraphicObject;
begin
   for I := 0 to Value.Count - 1 do
   begin
     NewItem := TGraphicObjectClass(Value[I].ClassType).Create;
     Add(NewItem);
     NewItem.Assign(Value[I]);
   end;
end;

[Dejan Vu]

Zitat von Bjoerk:

hier wünsch ich dir mit 70 Klassen viel Spaß:

samso hatte den Spaß.

[Bjoerk]

Nö, jeet nicht.

[Dejan Vu]

Wot? Wieso nicht? Wird nicht der gleiche Datentyp kreiert?