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;

[DeddyH]

Delphi-Quellcode:

procedure TShape.Paint;
begin
  case FTyp of
    Typ1:
      PaintTyp1;
    Typ2:
      PaintTyp2;
    Typ3:
      PaintTyp3;
    Typ4:
      PaintTyp4;
    Typ5:
      PaintTyp5;
    ..

    TypN:
  end;
end; 

procedure TShape.PaintTyp1;
begin
  ...
end;

procedure TShape.PaintTyp2;
begin
  ...
end;

//usw. usf.

[Bjoerk]

Jenau.

[Sir Rufo]

Wenn du das flexibel erweitern möchtest, dann nimm eine Shape-Klasse und eine ShapeStrategy-Klasse.
Hier mal skizziert, wie das geht:

Delphi-Quellcode:

type
  TShapeStrategy = class abstract
  protected
    procedure Paint( ACanvas : TCanvas ); virtual; abstract;
  end;

  TShapeStrategyClass = class of TShapeStrategy;

  TShape = class( TGraphicControl )
  private
    FStrategyName : string;
    FStrategy : TShapeStrategy;
    procedure SetStrategyName( const Value : string );
  protected
    procedure Paint; override;
  public
    class procedure RegisterStrategy( const AName : string; AStrategy : TShapeStrategyClass );
  published
    property StrategyName : string read FStrategyName write SetStrategyName;
  end;

procedure TShape.Paint;
begin
  if Assigned( FStrategy ) then
    FStrategy.Paint( Canvas );
end;

[Dejan Vu]

Zitat von Bjoerk:

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

Da sind keine Generics oder anonyme Methoden im Spiel, das ist richtig billig und schnell gebaut. Und Factories gibts im Wiki für lau zum anschauen.

Zitat von Bjoerk:

Delphi-Quellcode:

procedure TShape.Paint;
begin
  case FTyp of
    Typ1:

    Typ2:

    Typ3:
...

Das ist -mit Verlaub- nicht weitsichtig. Es verstößt gegen das OCP und ist auch so nicht sonderlich flexibel, denn jedes Shape hat ja u.U. individuelle Parameter oder unterscheidet sich im Verhalten (Stichwort Collisiondetection). Du legst dich bei diesem Pattern sofort darauf fest, das sich die Shapes nur im Aussehen unterscheiden.

Ring dich dazu durch, individuelle Klassen zu erstellen. Es ist mehr Tipparbeit, aber im Endeffekt machst Du das nur 1x, während Du bei der 'Case'-Variante (Non OOP) eh irgendwann refaktorisieren musst, weil das Design Quark ist.

Die Strategy-Idee von Sir Rufo löst das Paint-Case-Problem auf sehr elegante Weise und sollte dann verwendet werden, wenn in einer Klasse eine bestimmte Funktion flexibel änderbar sein sollte. Bezüglich der eventuell unterschiedlichen Eigenschaften (Höhe/Breite vs. Radius vs. Elipsenradien vs. äh... Schuhgröße) wirst Du mit dem Pattern dann nicht weit kommen.