Dry-Problem

[Delbor]

Hi zusammen

Zur Zeit arbeite ich an einem Dialog, um in verschiedenen Synedits die zugehörigen Highlighter bearbeiten zu können. Konkret: Es gibt 3 Frames mit je einem Synedit, die jeweils unterschiedliche Highlighter haben; je einen für CSS, HTML und Javascript.
Dementsprechend gibt es 3 Frames mit unterschiedlichen Feldern vom Typ TSynHighlighterAttributes (9, bzw. 12). Da dies Klassen sind, müssen die Dinger erstmal erstellt werden. Das geschieht zurzeit in jeweils einer eigenen Prozedur, also in ebensovielen Proceduren, wie Felder vorhanden sind. Das sieht dann - ausschnittweise - so aus:

Delphi-Quellcode:

procedure TJavaScriptAttributsFrame.SymbolAttributesCreate;
begin
  FSymbolAttri := TSynHighlighterAttributes.Create;
  FJavaScriptAttributsList.Add(FSymbolAttri);
  CmbxAttributes.Items.AddObject('Symbole',TObject(FSymbolAttri));
  Application.ProcessMessages;
end;

procedure TJavaScriptAttributsFrame.StringAttributesCreate;
begin
  FStringAttri := TSynHighlighterAttributes.Create;
  FJavaScriptAttributsList.Add(FStringAttri);
  CmbxAttributes.Items.AddObject('Strings',TObject(FStringAttri));
  Application.ProcessMessages;
end;

procedure TJavaScriptAttributsFrame.SpaceAttributesCreate;
begin
  FSpaceAttri := TSynHighlighterAttributes.Create;
  FJavaScriptAttributsList.Add(FSpaceAttri);
  CmbxAttributes.Items.AddObject('Leerzeichen',TObject(FSpaceAttri));
  Application.ProcessMessages;
end;

In der Unit, aus der dieser Code stammt, gibt es insgesammt 9 solcher Prozeduren. Was an diesem Beispiel deutlich wird: die Dinger haben alle den selben Aufbau, einzig die TSynHighlighterAttributes-Instanzen unterscheiden sich - ein klarer Fall für DRY.

Nur bei der Umsetzung bleibe ich schon im Vorfeld (Vorgehensweise in Gedanken formulieren) stecken. Ziel wäre hier eine einzige Createprozedure, die beim iterieren durch ein Set of TSynHighlighterAttributes die benötigten Instanzen erstellt. Ohne das jemals gemacht zu haben und ohne Kenntnis eines entsprechenden Beispiels sollte sowas möglich sein:

Delphi-Quellcode:

TSynattri = (FStringAttri,FSpaceAttri,....);
TSynattribute = Set of TSynattri;

...
...

SynHighlighterAttribute[i]:= TSynHighlighterAttributes[i].Create

FJavaScriptAttributsList ist eine generische Objectliste, CmbxAttributes eine Combobox, die es ermöglicht, den 9 Objekten auf einer einzigen Oberfläche Werte zuzuweisen(Schriftstil, Schriftfarbe).

Probleme bereiten mir dabei allerdings die Strings, die ich in der Procedur der Combobox zuweise.
Wie würdet ihr das lösen?

Gruss
Delbor

[Sir Rufo]

Das ist erst mal ein Fall für das Flyweight-Pattern. Damit holst du dir die benötigen Instanzen.

Da du auch noch eine Beschreibung benötigst, wird das Attribut einfach nochmal gekapselt:

Delphi-Quellcode:

type
  TLabeledFlyweight<TIndex,T:class> = class
  private
    FLabel : string;
    FIndex: TIndex;
    FFlyWeight: TFlyWeight<TIndex,T>;
    private GetObject : T;
  public
    public constructor Create( const ALabel: string; AIndex: TIndex; AFlyWeight: TFlyWeight<TIndex,T> );
    property Label: string read FLabel;
    property &Object: string read GetObject;
  end;

function TLabeldFlyweight<TIndex,T>.GetObject : T;
begin
  Result := FFlyweight[FIndex];
end;

[BUG]

Zitat:

Zitat von Sir Rufo (Beitrag 1309631)

Das ist erst mal ein Fall für das Flyweight-Pattern.

Irgendwie sehe ich nicht, was das Problem mit dem Flyweigth-Pattern zu tun hat.

Im Prinzip könnte das Ganze über ein Verzeichnis realisiert werden. Die Dialoge fordern ihre gewünschten Attribut an, der Dialog mit der ComboBox kann sich alle Attribute und ihre Namen aufzählen lassen.

[Sir Rufo]

Zitat:

Zitat von BUG (Beitrag 1309646)

Zitat:

Zitat von Sir Rufo (Beitrag 1309631)

Das ist erst mal ein Fall für das Flyweight-Pattern.

Irgendwie sehe ich nicht, was das Problem mit dem Flyweigth-Pattern zu tun hat.

Im Prinzip könnte das Ganze über ein Verzeichnis realisiert werden. Die Dialoge fordern ihre gewünschten Attribut an, der Dialog mit der ComboBox kann sich alle Attribute und ihre Namen aufzählen lassen.

Instanzen, die über einen Schlüssel aus einem Verzeichnis geliefert werden (ja, das beschreibt das Flyweight-Pattern sehr treffend)

[CarlAshnikov]

Geht das in die richtige Richtung?

Delphi-Quellcode:

procedure TJavaScriptAttributsFrame.AddAttribute(var AAttrib: TSynHighlighterAttributes; const AName: string);
begin
  AAttrib:= TSynHighlighterAttributes.Create;
  FJavaScriptAttributsList.Add(AAttrib);
  CmbxAttributes.Items.AddObject(AName,TObject(AAttrib));
  Application.ProcessMessages;
end;

procedure TJavaScriptAttributsFrame.AddAttributes;
begin
  AddAttribute(FSpaceAttri, 'Leerzeichen');
  AddAttribute(FStringAttri, 'Strings');
  AddAttribute(FSymbolAttri, 'Symbole');
end;

[BUG]

Zitat:

Zitat von Sir Rufo (Beitrag 1309652)

Instanzen, die über einen Schlüssel aus einem Verzeichnis geliefert werden (ja, das beschreibt das Flyweight-Pattern sehr treffend)

Überhaupt nicht :shock:
Das herausragende Merkmal von Flyweight ist, das Operationen von außen ein einen (geteilten) Zustand oder Kontext bekommen. Dieser Zustand kann ein Verzeichnis sein, kann aber auch irgendetwas völlig anderes sein.

Zitat:

Zitat von CarlAshnikov (Beitrag 1309656)

Geht das in die richtige Richtung?

Das beseitigt zumindest den wiederholten Code, allerdings wird es bei gleichem Namen auch unterschiedliche Instanzen geben. z.B. 'Strings' könnte mehrfach in der Combobox auftauchen.

[Delbor]

Hi zusammen

Zitat:

Die Dialoge fordern ihre gewünschten Attribut an, der Dialog mit der ComboBox kann sich alle Attribute und ihre Namen aufzählen lassen.

Eigentlich wird es genau einen Dialog geben, der auf einem Pagecontrol mit 3 Tabsheets je einen Frame enthält (TJavaScriptAttributsFrame,TCssAttributsFrame,THTM LAttributsFrame).
Im Synedit, bzw. den Hightlighten dazu, sind die Propertys für Schriftstile, Farben etc vom Tip TSynHighlighterAttributes. Und deshalb sind die privaten Felder meiner Frames, welche für das Highlightning zuständig sind, auch von diesem Typ.
Diese Dinger werden im constructor des Frames erzeugt, während ich die Freigabe der Objectliste überlasse.
Der Dialog und damit die Frameinstanzen werden dynamisch beim Aufruf erzeugt und zerstört, wenn der Dialog geschlossen wird.
Über die Combobox kann das Objekt gewählt werden, dessen Farbben und Stile bearbeitet werden sollen.

Da mir bis anhin das Flyweigth-Pattern unbekannt war, hab ich mal danach gegoogelt; ich weiss zwar nicht genau, ob ich da schon alles verstanden habe, aber ich denke mal, dass es innerhalb der bestehenden Synedit-Quellcodes wohl eher Berechtigung hätte, da dort reger Gebrauch von Objekten gemacht wird, die sich in vielen Teilen ähneln.

Mir ist aber etwas aufgefallen: TSynHighlighterAttributes ist eine Klasse, und Klassen kann man Namen zuweisen - zum Beispiel den String, den ich der Combobox als Item zuweise (Offenbar hatten die vergangenen Hitzetage unliebsame Auswirkungen...).

Aber auch wenn der Dialog und seine Frames nur temporär bestehen, bräuchte ich diese Klassen möglicherweise gar nicht, sondern gerade mal völlig normale Records:

Delphi-Quellcode:

  TAttributsRec = Record
     BackGround : TColor;
    FoeGround : TColor;
    StyleBold :Boolean;
    StyleItalic : Boolean;
    StyleUnderLine : Boolean;
    StyleStrikeOff : Boolean;
    AttributName: String;

Nun war ich fast fertig, da hab ich einige neue Antworten gesehen,, weshalb ich eine Erweiterung anhänge:

Delphi-Quellcode:

procedure TJavaScriptAttributsFrame.SymbolAttributesCreate;
begin
  FSymbolAttri := TSynHighlighterAttributes.Create;
  FSymbolAttri.Name := 'Symbole';           //<== Damit steht ein String zur Verfügung
  FJavaScriptAttributsList.Add(FSymbolAttri);
  CmbxAttributes.Items.AddObject(FSymbolAttri.Name,TObject(FSymbolAttri));
  Application.ProcessMessages;
end;

Nein, das geht nicht nur in die richtige Richtung - das ist die Lösung. Irgendwie schwirrten mir Listen durch den Kopf, von wo aus aufgerufen werden sollte - aber was, wenn so eine Liste mal aus irgendeinem Grund umsortiert wird (Die Bluescreens während der Hitzewelle waren auch nicht vorgesehen...)?

Gruss
Delbor

[Delbor]

Hi zusammen

Zitat:

... allerdings wird es bei gleichem Namen auch unterschiedliche Instanzen geben. z.B. 'Strings'

Jein... Natürlich kann der Aufruf theoretische beliebig oft erfolgen, und so könnten theoretisch beliebig viele Instanzen existieren. Wirklich benötige ich aber gerade mal je eine Instanz für meine 3 Frameklassen, egal, wieviele Instanzen dieser SyneditFrames es gibt.

Gruss
Delbor

[Sir Rufo]

Zu einem Flyweight gehört auch eine Flyweight-Factory und genau diese beiden kann man hier hervorragend einsetzen.

Entweder global für alle Frame-Instanzen (alle Einstellungen sind gleich) oder eben pro gewähltem Context, wobei man den dann auch wieder in ein Flyweight/Flyweight-Factory packen kann.

[Delbor]

Hi zusammen

Nachdem ich einerseits den Vorschlag von CarlAshnikov in Code umgesetzt und andrerseits, wenigstens gefühlsmässig, das halbe Internet nach dem von Sir Rufo vorgeschlagenen Flyweight-Pattern sowie den Generics-Hilfeseiten bei Embarcadero durchsucht/studiert habe, habe ich mal versucht, mein Testprogramm zu starten - und kriegte prompt so in etwa 11 Fehler um die Ohren geschlagen...:-D

Das Korpus Delicti sind schon mal meine Createprozeduren. Die TSynHighlighterAttributes ist in den Sourcen der Synedit-Suite deklariert - ich hab mich dafür entschieden, die in den Frames einstellbaren Werte in einem solchen Objekt zu übergeben, nicht zuletzt, weil das Synedit es genauso macht. Aber auch wegen meiner ursprünglicheen Absicht, die Einstellungen meiner Frames per Events zu übergebn - meine Oberflächen sollen sich aus möglichst völlig unabhängiggen Modulen zusammenstellen, so dass ich diese Module ohne Anpassungungen wiederverwenden kann.
Die Deklaration der Klasse TSynHighlighterAttributes in den Synedit-Sourcen:

Delphi-Quellcode:

constructor Create(AName: string; AFriendlyName: UnicodeString);

Nun wäre es wohl einfach, genau diese Deklaration zu übernehmen - wenn es da nicht ein klitzekleines Problemchen gäbe: trotz bisherigem doch recht intensivem Studium der Synedit-Sourcen bin ich bislang nicht dahintergekommen, für was der Parameter FriendlyName steht.
Weiss jemand mehr? Und grundsätzlich: was macht eine Klasse mit zwei Namen??

Gruss
Delbor