Delphi-PRAXiS - Delphi Best Practice Aggregation von Informationen

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)

- Algorithmen, Datenstrukturen und Klassendesign (https://www.delphipraxis.net/78-algorithmen-datenstrukturen-und-klassendesign/)

- - Delphi Best Practice Aggregation von Informationen (https://www.delphipraxis.net/184058-best-practice-aggregation-von-informationen.html)

Best Practice Aggregation von Informationen

Hallo zusammen,

ich bin gerade etwas am rumspielen und würde mir gerne Eure Meinungen und Vorschläge zu einem bestimmten Thema einholen.
Im Detail beschäftige ich mich gerade mit der Gestaltung einer Tabellenkomponente.

Vorab schonmal sorry für die Beitragslänge, ich konnte aber irgendwie auch kein Spoiler-Tag ausfindig machen um das ganze leserlicher zu gestalten ;-( Wo find ich das denn ?

Folgendes Szenario:
Eine Tabelle besteht wie gewohnt aus einem Layout von Spalte (Column), Zeile (Row) und Zelle (Cell).
Diese drei Elemente müssen je nach Vorstellung die verschiedensten Eigenschaften bereitstellen, wie z.B. Möglichkeiten zur Selektion, Lokalisierung, Sichtbarkeit und Identifizierung.

Um im weiteren Entwicklungsverlauf flexibel zu bleiben, war die Idee aus den genannten Eigenschaften je eine Schnittstelle bereitgestellt (GUIDs habe ich fürs Lesen mal weggelassen):

Delphi-Quellcode:

			  ISelectable = interface(IInvokable)

    procedure Select;

    procedure Deselect;

    function IsSelected;

  end;

  ILocatable = interface(IInvokable)    

    function Coordinate: TCoordinate;

  end;

  IDisplayable = interface(IInvokable)    

    function IsVisible: boolean;

  end;

  IIdentifiable = interface(IInvokable)    

    function UUID: String;

  end;

Wo ich mir nun absolut unschlüssig bin, ist das Bereitstellen der Eigenschaften (Selektion, Lokalisierung, Sichtbarkeit und Identifizierung) für Zeile, Spalte und Zelle - unter der Voraussetzung, dass Zeile, Spalte und Zelle InterfacedObjects bleiben. Wie würdet Ihr die Interfaces gestalten, oder was würdet Ihr komplett anders machen?:

Delphi-Quellcode:

			 IRow = interface(IInvokable)                    

  end;

  IColumn = interface(IInvokable)                    

  end;

  ICell = interface(IInvokable)                    

  end;

1. die Interfaces der Elemente bei jeder weiteren Eigenschaft erweitern und fest verdrahten?

Interfaces:

Delphi-Quellcode:

			  IRow = interface(IInvokable)    

    function Selectable: ISelectable;

    function Locatable: ILocatable;

    function Displayable: IDisplayable;

    function Identifiable: IIdentifiable;

  end;

  IColumn = interface(IInvokable)    

    function Selectable: ISelectable;

    function Locatable: ILocatable;

    function Displayable: IDisplayable;

    function Identifiable: IIdentifiable;

  end;

  ICell = interface(IInvokable)    

    function Selectable: ISelectable;

    function Locatable: ILocatable;

    function Displayable: IDisplayable;

    function Identifiable: IIdentifiable;

  end;

Verwendung also:

Delphi-Quellcode:

			....

var

  LRow: IRow;

begin

 DoThingsWithUUID( LRow.Identifiable.UUID );

end;

....

2. die Interfaces der Elemente nur Element-Spezifische Infos tragen lassen, und die allgemeinen Eigenschaften der Implementierung überlassen und casten?

Interfaces:

Delphi-Quellcode:

			  IRow = interface(IInvokable) 

    procedure DoThingsOnlyRowsDo;                 

  end;

  IColumn = interface(IInvokable)                    

    procedure DoThingsOnlyColumnsDo;

  end;

  ICell = interface(IInvokable)

    procedure DoThingsOnlyCellsDo;                    

  end;

Beispielimplementierung:

Delphi-Quellcode:

			...

TRow = class(TInterfacedObject,

                        IRow,

                        IIdentifiable,

                        IDisplayable,

                        ILocatable)

...

Verwendung also:

Delphi-Quellcode:

			....

var

  LRow: IRow;

begin

 DoThingsWithUUID( (LRow AS IIdentifiable).UUID );

end;

....

3. Aggregation der Informationen über eine Art Extension?

Interfaces:

Delphi-Quellcode:

			  IRow = interface(IInvokable) 

    procedure DoThingsOnlyRowsDo;                 

  end;

  IColumn = interface(IInvokable)                    

    procedure DoThingsOnlyColumnsDo;

  end;

  ICell = interface(IInvokable)

    procedure DoThingsOnlyCellsDo;                    

  end;

Beispielimplementierung:

Delphi-Quellcode:

			...

TRow = class(TInterfacedObject,

                        IRow,

                        IIdentifiable,

                        IDisplayable,

                        ILocatable)

...

Extension:

Delphi-Quellcode:

			  Row = record

  private

    fThis: IRow;

    function GetThis: IRow;

  public

    constructor Create(const AValue: IRow);

    class operator Implicit(const value: Row): IRow;

    function AsIdentifiable: IIdentifiable;

    function AsDisplayable: IDisplayable;

    function AsLocatable: ILocatable;

  end;

Verwendung also:

Delphi-Quellcode:

			procedure DoThingsWithRow(const ARow: IRow);

var

  LRow: Row;

begin

 LRow.Create(ARow);

 DoThingsWithUUID( LRow.AsIdentifiable.UUID );

end;

....

AW: Best Practise Aggregation von Informationen

Ey Alda, ;-)

ich würde in Deinem Fall überlegen, ob Dir Interfaces hier etwas bringen.

Du willst offenbar eine fixe Gitterkomponente bauen. Interfaces würden Dir ermöglichen, die aktuellen Zellen irgendwann durch andere Klassen zu ersetzen. Außerdem würden die Zellen automatisch freigegeben, wenn sie nicht mehr genutzt werden.
Bei einer Gitterkomponente würde ich erst mal denken, dass beides nicht unbedingt notwendig ist. Der Gitterkomponente können ja ruhig alle TRow, TColumn und TCell bekannt sein und sie kann die entsprechenden Objekte in eigener Kontrolle erzeugen, verwalten und freigeben.

Also Interfaces sind möglicherweise nicht wirklich hilfreich!?
(Und warum IInvokable statt IInterface?)

OK, wenn Interfaces, dann würde ich Weg 2 gehen.
Es handelt sich hier um direkte Eigenschaften der Klassen. ISelectable wird unterstützt, wenn es der Klasse zugewiesen ist. Fertig.

Im Weg 1 müsstest Du ein Objekt erzeugen und es ISelectable zuweisen. Sonst wäre es nil.
Das würde ich so anwenden, wenn man z.B. ein Auto zusammenbaut. Lenker und Motor können dann als Instanzen verwaltet werden. Auf dem Fließband ist der Motor zunächst noch nil. Erst zum Schluss wird eine Motorinstanz eingebaut.

Ich fände das für Deinen Anwendungsfall zu umständlich und unpassend.

Weg 3 würde ich ausschließen. Warum willst Du auf einmal mit Records arbeiten. (Kann sein, dass das machbar ist, aber das erscheint mir erst mal nicht ganz plausibel).

AW: Best Practise Aggregation von Informationen

Zitat: