Setter mehrfach überschreiben.

[stahli]

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

[himitsu]

Zitat:

Zitat von stahli (Beitrag 1304861)

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. :stupid:

[Dejan Vu]

Zitat:

Zitat von Bjoerk (Beitrag 1304856)

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:

Zitat von Bjoerk (Beitrag 1304704)

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:

Zitat von Bjoerk (Beitrag 1304801)

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:

Zitat von Bjoerk (Beitrag 1304942)

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:

Zitat von Bjoerk (Beitrag 1304934)

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?

[Bjoerk]

Probiers halt aus. Variante wäre direkt mit TGraphicObjectClass zu arbeiten, das geht. Dann kann aber nicht mehr Is Typ1,2,3 abfragen.

So getestet:

Delphi-Quellcode:

  TObject0 = class
  private
    FA: integer;
    FB: integer;
    FC: integer;
  public
    property A: integer read FA write FA;
    property B: integer read FB write FB;
    property C: integer read FC write FC;
    procedure Assign(Value: TObject0); virtual;
  end;

  TObject1 = class(TObject0)
  private
    FSL: TStringList;
  public
    property SL: TStringList read FSL;
    procedure Assign(Value: TObject0); override;
    constructor Create;
    destructor Destroy; override;
  end;


{ TObject0 }

procedure TObject0.Assign(Value: TObject0);
begin
  FA := Value.A;
  FB := Value.B;
  FC := Value.C;
end;

{ TObject1 }

procedure TObject1.Assign(Value: TObject0);
var
  O: TObject1;
begin
  inherited;
  O := TObject1(Value);
  FSL.Assign(O.SL);
end;

constructor TObject1.Create;
begin
  inherited;
  FSL := TStringList.Create;
end;

destructor TObject1.Destroy;
begin
  FSL.Free;
  inherited;
end;

procedure TTestForm.Button1Click(Sender: TObject);
type
  TObjectClass = class of TObject0;
var
  A: TObject1;
  B: TObject0;
begin
  A := TObject1.Create;
  try
    B := TObjectClass(A.ClassType).Create;
    try
      B.Assign(A);
    finally
      B.Free;
    end;
  finally
    A.Free;
  end;
end;

[Dejan Vu]

Hab kein Delphi, aber dafür brauchst Du dann doch wieder eine Basisklasse:

Delphi-Quellcode:

TBasisKlasse = Class
   public constructor Create; Virtual;
End;

  TA = Class (TBasisKlasse) end;
  TBasis = class of TBasisKlasse;

Constructor TBasisKlasse.Create; begin end;


Var
  a,b : TBasisKlasse;

begin
  a := TA.Create;
  b := TBasis(a.ClassType).Create;
end;

getippt und nicht getestet.

[Bjoerk]

Liest du die Posts eigentlich? :gruebel:

TObject0 ist die Basisklasse. Und ja, ich hab auch eine. Siehe Posts 1- 10, die Kommentare in #9. Die TWerkzeug gibst nur nicht mehr.

[stahli]

Das Problem ist, dass sich Deine Beispiele immer auf Deine aktuelle Projektstruktur beziehen und losgelöst nicht so ganz klar sind.

Mein Vorschlag:

Baue Dir mal ein völlig eigenständiges Testprojekt mit Fahrzeugen (Auto, Fahrrad, Boot), Tieren (Ente, Fisch) und Früchten (Apfel, Banane).
So siehst Du eindeutig, welche Klassen Gemeinsamkeiten haben und welche nicht.

Die Klassen brauchen ja nichts wirklich zu machen. Wenn alles kompilierbar ist, reicht das ja schon aus.

Ich hatte das mal bei einer Interface-Demo so gemacht:
http://www.delphipraxis.net/183702-i...-factorys.html

[Dejan Vu]

Zitat:

Zitat von Bjoerk (Beitrag 1304974)

Liest du die Posts eigentlich?

Ich versuche es. Einmal hast du keine Basisklasse,

Zitat:

Zitat von Bjoerk (Beitrag 1304934)

Die Basisklasse gibt es nicht mehr

Dann wieder doch.

Zitat:

Zitat von Bjoerk (Beitrag 1304974)

TObject0 ist die Basisklasse.

Da muss man doch durcheinanderkommen.
Verpasse TObject0 einen virtuellen Konstruktor und dann kann man auch Objekte anhand des 'ClassType' erzeugen.
Damit kannst Du klonen und alles ist gut. Die Operationen auf deine Figuren bildest du über einzelne Arbeiter ab, die Du dann über die Figurklasse per Faktory erzeugst. Wenn Du das auf die Spitze treiben willst, baue Dir eine Factory-Factory und dann ist das richtig geil (also OCP-technisch)

Tipparbeit: Ja.
Übersichtlich: Ja.
Oop: Ja.
SRP+OCP konform: Ja.

Aber natürlich führen auch andere Wege zum Ziel.