Design Problem (Shapes)

[Bjoerk]

Ich hab ein Design Problem. Ich hab 44 Typen von Shapes. Aus den 44 werden wohl mal im Laufe der Zeit mal 144 werden. Ich hab zwei Varianten des Quellcodes. Einmal als separate Klassen mit override Methoden und einmal alles in einer Klasse. Beides ist irgendwie Mist weil beides ziemlich unübersichtlich. Liegt das in der Natur der Sache oder gibt’s generell auch noch andere Möglichkeiten diesen Quellcode aufzusetzen?

[Uwe Raabe]

Das kommt ganz auf deine Anforderungen an, die wir aber jetzt nicht kennen.

Eventuell bietet sich hier auch das Strategy-Pattern an. Ein Beispiel kann ich aber ohne weitere Code-Kenntnis schlecht geben.

[Bjoerk]

Von der Struktur her so:

Delphi-Quellcode:

type
  TBaseObject = class
  protected
    vars;
    getter, setter;  virtual;
  public
    methods; virtual;
    methods; virtual; abstract;
    properties;
  end;


  TObject1..N = class(TBaseObject)
  private
    more vars;
  protected
    more vars;
    more getter, setter;
    getter, setter;  override;
  public
    methods;
    methods; override;
    properties;
  end;

[Uwe Raabe]

Da sich das Verhalten der 44-144 Shapes per Definition unterscheidet, kommst du um eine entsprechende Menge Code nicht herum. Das jetzt alles in eine Klasse zu packen widerstrebt mir persönlich schon sehr, ist aber durchaus ein möglicher Ansatz. Einzelne Klassen mit einer passenden Vererbungshierarchie sind mir da schon lieber - aber das ist meine persönliche Meinung.

Wenn du allerdings feststellst, daß du wiederkehrende oder ähnliche Code-Teile hast, sollte man über einen besseren Ansatz nachdenken. Da fallen mir spontan noch Anonyme Methoden und Generics ein, aber für einen fundierten Rat müsste man schon mehr sehen.

[Dejan Vu]

Du kannst deine 144 Shapes ruhig so umsetzen, solltest Du sogar, wenn Du OOP machen willst.

Um elegant das richtige Shape zu instantiieren, bietet sich eine Factory an. Entweder haben die Klassen alle irgend einen Namen/Enum-Wert, oder du kannst sie klassifizieren. Mögliche Schnittstelle der ShapeFactory:

Delphi-Quellcode:

myShape := ShapeFactory.Create(shapeBigCircle); // via Enum
myShape := ShapeFactory.Create(TBigCircle); // by class, fast so wie direktes Create, aber mit mehr Möglichkeiten

// oder vielleicht mit einer ShapeFactoryFactory:
myFactory := ShapeFactoryFactory.CreateFactory(shapesCircles);
myShape := myFactory.Create(circleBig);

Ordnung bringt hier im Übrigen nur eine stringente Nomenklatur und Dokumentation. Mit einer Factory hast Du eine Dokumentation geschaffen, denn alle Shapes sind zentral (in der Factory) erfasst. Dort lässt sich auch die Nomenklatur überprüfen, einfach, weil in der Registrierung ja eh alle Namen stehen und da fällt es schon auf, wenn man bei der Benennung der Klassen geschludert hat.

Delphi-Quellcode:

Procedure TShapeFactory.Register;
Begin
  RegisterShape (TBigCircle, shapesBigCircle);
  RegisterShape (TKleinerKreis, shapesSmallCircle); // <-- Möööp
...

[Bjoerk]

Ok. Tanx. Von Factorys hab ich keinen Plan? Anonyme Methoden und Generics sind halt auch etwas ungünstig bei D2007.

Wenn das TShape von Delphi nicht 6 sondern 60 Typen hätte, wie wäre das denn programmiert worden, wenn man eine ellenlange Paint hätte vermeiden wollen und auch nicht 60 verschiedene Klassen hätte haben wollen?

Delphi-Quellcode:

procedure TShape.Paint;
begin
  case FTyp of
    Typ1:

    Typ2:

    Typ3:

    Typ4:

    Typ5:

    ..

    TypN:
  end;
end;