![]() |
AW: Fluent Design und Records
@stahli
Das Besondere am Fluent Interface ist kein Ersatz für
Delphi-Quellcode:
sondern das hier
Result := CreateSomeInterface;
Result.DoSomething('withParameter'); Result.DoSomethingOther; Result.ConvertEverythingTo;
Delphi-Quellcode:
Natürlich ist es möglich das alle ResultX vom gleichen Typ sind und dann auch auf die gleiche Instanz verweisen, aber sie müssen es eben nicht.
ResultA := CreateSomeInterface; // IFoo
ResultB := ResultA.DoSomething('withParameter'); // IBar ResultC := ResultB.DoSomethingOther; // IOther ResultD := ResultC.ConvertEverythingTo; // string Und die eingebaute Code-Formatierung formatiert das so (wenn man einen Zeilenkommentar anhängt)
Delphi-Quellcode:
Result := CreateSomeInterface() // IFoo
.DoSomething('withParameter') // IBar .SoSomethingOther() // IOther .ConvertEverythingTo(); // string |
AW: Fluent Design und Records
Es gibt mehrere Gründe den Sourcecode "so" zu schreiben.
Beispiel SQL:
Delphi-Quellcode:
Wie üblich die
TCRUDSearch.&For(fPerson).Where('NAME').LIKE(LastName.Trim)
{} .begin_Optional(FirstName.Trim <> '') {} ._AND.Where('VORNAME').LIKE(FirstName.Trim) {} .end_Optional.OrderBy('NAME') {} .OrderBy('VORNAME ASC') {} .Limit(100) {} .Start(SearchResult);
Delphi-Quellcode:
, damit der Formatter das nicht zerstört.
{}
Nicht nur das ich mit diesem Interface keine Tippfehler mehr im "SQL-Source-Text" habe, ich kann auch mit dem "begin Optional(Statement)" je nach Kondition des Statements einen anderen SQL Code erzeugen. oder halt sowas:
Delphi-Quellcode:
Ich empfehle hierzu mein
TFMXFluentCreator<TDayLBL>.CreateDefault(FDayLBL[i-1],LConfig)
{} .FontSize(FFontSize) {} .Skip(LConfig.Trim <> '',2).FontColor(LDisplayDay.Color).FontBold(LDisplayDay.Bold) {} .Text(FDays[i-1]) {} {$IFNDEF NOHints} {} .Skip((LDisplayDay.Hint = '')).Hint(LDisplayDay.Hint) {} {$ENDIF} {} ; ![]() Hier gibe es wie bei meine SQL Creator (begin/end) ein Skip Command mit dem man 1-N der nächsten Fluent-Aufrufe überspringen kann je nach Kondition. Per LConfig kann ich Aufruf die ich beliebig vordefinieren kann, zusätzlich abrufen. Wenn man ListBoxItems im Source erzeugen möchte ist das eine fürchterliche Tipperei, besonders durch die TWhateverbezeichner.Value {$SCOPEDENUMS ON}. Da sieht es doch schon deutlich einfacher aus, wenn man
Delphi-Quellcode:
schreiben kann..
TFMXFluentCreator<TListBoxItem>.RegisterDefault(Procedure (LBI : TFMXFluentCreator<TListBoxItem>)
begin LBI.Style('listboxitembottomdetail') .Height(49) .Parent(ListBox1) .ItemMore.OnClick(Procedure (Sender : TObject) begin AViewModel.Edit((Sender as TListBoxItem).TagString); Translate.SetFocus; end,false); end); Grüsse Mavarik :coder: |
AW: Fluent Design und Records
Zitat:
Zum Debuggen wäre natürlich eine Variable einfacher:
Delphi-Quellcode:
Aber das versaut das "schöne" dann komplett. ;-)
Result := CreateSomeInterface;
Result := Result.DoSomething('withParameter'); Result := Result.DoSomethingOther; Result := Result.ConvertEverythingTo; (Vorausgesetzt, es ist durchgehend derselbe Interface-Typ, denn wie Schokohase schon schrieb: Das ist nicht notwendigerweise der Fall. Wenn nicht, muesste man auch noch jede Menge Variablen deklarieren, was noch viel mehr Tipperei ist.) Ich habe einige wenige solcher Konstruktionen, bei denen diese Kaskade einen Funktionsaufruf mit zig Parametern ersetzt hat. Die Lesbarkeit hat es auf jeden Fall verbessert. |
AW: Fluent Design und Records
Zitat:
Es ist halt immer ein Kompromiss zwischen "schön" bzw. lesbar und leichter zu debuggen. Zitat:
Delphi-Quellcode:
Ach ja, früher galt with auch als richtig cool, weil man da soviel Tipperei spart.
begin
var ResultA: IFoo := CreateSomeInterface; // IFoo var ResultB: IBar := ResultA.DoSomething('withParameter'); // IBar var ResultC: IOther := ResultB.DoSomethingOther; // IOther var ResultD: string := ResultC.ConvertEverythingTo; // string end; |
AW: Fluent Design und Records
Solche Zwischenschritte in einzelne Variablen zu speichern stört mich gar nicht. Ich finde, das erhöht sogar die Übersichtlichkeit deutlich.
Das mache ich auch schon mal bei etwas komplizierteren Berechnungen (Winkel o.ä.). Da nehme ich gern in Kauf, mal eine Variable anzulegen. Einzig, eine ständige Wiederholung der gleichen Variable würde ich u.U. gern vermeiden, wenn es dafür eine abgekürzte Darstellung/Schreibweise gäbe (Alternative zum with). Meine Klassen würde ich dafür aber nicht umbauen. In Bezug auf "Tipparbeit vermeiden" fallen mir da ganz andere Themen ein, die ich wirklich wichtig fände und wo die IDE wirklich keine Hilfe ist. |
AW: Fluent Design und Records
Naja sagen wir mal so...
Für ein Interface, Klasse oder Record das man so verwendet/erstellt bietet es sich natürlich an, einen Unittest zu schreiben, dann braucht man i.d.R. auch nicht debuggen oder eher selten. Mavark :coder: |
AW: Fluent Design und Records
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:21 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz