Fluent Design und Records

[dummzeuch]

Zitat von peterbelow:

Zitat von hschmid67:

Result := CreateSomeInterface.DoSomething('withParameter').DoSomethingOther.ConvertEverythingToString; Das ist an manchen Stellen sehr praktisch und macht den Code in meinen Augen etwas schöner, vor allem, wenn man mit Interfaces statt mit Objekten arbeitet.

Naja, Schönheit liegt im Auge des Betrachters.

Stell Dir mal vor, Du mußt sowas debuggen, dann ist es nicht mehr so schön...

Einfach vernuenftig formatieren ...

Delphi-Quellcode:

Result := CreateSomeInterface
  .DoSomething('withParameter')
  .DoSomethingOther
  .ConvertEverythingTo

... und schon ist das kein Problem mehr. Und lesbarer ist es (IMHO) auch.
(Ob der OP das dann allerdings immernoch "schön" findet?).

[HolgerX]

Hmm..

Zitat von dummzeuch:

Zitat von peterbelow:

Zitat von hschmid67:

Result := CreateSomeInterface.DoSomething('withParameter').DoSomethingOther.ConvertEverythingToString; Das ist an manchen Stellen sehr praktisch und macht den Code in meinen Augen etwas schöner, vor allem, wenn man mit Interfaces statt mit Objekten arbeitet.

Naja, Schönheit liegt im Auge des Betrachters.

Stell Dir mal vor, Du mußt sowas debuggen, dann ist es nicht mehr so schön...

Einfach vernuenftig formatieren ...

Delphi-Quellcode:

Result := CreateSomeInterface
  .DoSomething('withParameter')
  .DoSomethingOther
  .ConvertEverythingTo

... und schon ist das kein Problem mehr. Und lesbarer ist es (IMHO) auch.
(Ob der OP das dann allerdings immernoch "schön" findet?).

So etwas ist immer gefährlich....

Was ist, wenn es beim '.DoSomething('withParameter')' kracht oder etwas geliefert wird, was in '.DoSomethingOther' zur Exception führt?

Wenn ich das in einer Zeile schreibe, wie kann ich dann im Debugger erkennen, wo es geknallt hat?

(Nur so meine Meinung )

[stahli]

Mal eine Frage, was Ihr grundsätzlich von einer solchen Darstellung haltet (mal völlig unabhängig von Delphi und anderen realen Sprachen).
Es geht mir nur um die reine Lesbarkeit und Wünsche diesbezüglich.

Das wäre ja Delphi ohne irgendwelche Klimmzüge:

Code:

  Result := CreateSomeInterface;
  Result.DoSomething('withParameter');
  Result.DoSomethingOther;
  Result.ConvertEverythingTo;

Warum will man das anders darstellen?
Um nicht mehrfach "Result" zu schreiben?

---

Ok, wenn man jetzt (rein hypothetisch!) dem IDE-Editor folgendes beibringen könnte:
"Wenn in den folgenden Zeilen das gleiche erste Wort steht und dann ein Punkt folgt, dann lasse das erste Wort in der Darstellung weg und rücke alles ab dem Punkt ein!"
dann würde das so aussehen:

Code:

  Result := CreateSomeInterface;
         .DoSomething('withParameter');
         .DoSomethingOther;
         .ConvertEverythingTo;

---

Da aber dann der Editor abweichenden Code darstellen müsste als der, den der Compiler erhält, müsste man das etwas anders aufziehen:
Man müsste dem Compiler sagen: "Wenn eine Anweisung mit einem Punkt beginnt, dann denke Dir mal, dass davor die Variable steht, der in der vorherigen Anweisung etwas zugewiesen wurde."
Die IDE könnte einfach die Anweisung ab dem Punkt einrücken.

Code:

  Result := CreateSomeInterface;
         .DoSomething('withParameter');
         .DoSomethingOther;
         .ConvertEverythingTo;

Das sähe also aus wie bei der vorherigen Überlegung, aber der Code wäre identisch zur Darstellung.
Das hätte den Haken, dass man letztlich nur in Verbindung mit der Einrückung klar erkennt, was dort gemeint ist.

---

Gut, schauen wir uns mal with an:

Code:

  Result := CreateSomeInterface;
  with Result do
  begin
    DoSomething('withParameter');
    DoSomethingOther;
    ConvertEverythingTo;
  end;

Eigentlich ja gar nicht sooo schlecht, allerdings bekannter Maßen mit einem recht hohen Verwechslungsrisiko und die Umschließung mit begin..end ist auch etwas nervig.

---

Mich würde das zu folgenden gewünschten Sprachfeature führen: "use"

Code:

  use Result := CreateSomeInterface;
             .DoSomething('withParameter');
             .DoSomethingOther;
             .ConvertEverythingTo;
             Report(.Text);
  Report('use gilt nicht mehr');

"use" würde with entsprechen und so lange gelten, wie folgende Anweisungen Bezeichner benutzen, die mit einem Punkt anfangen.
Dann wäre auch noch die Report-Anweisung möglich.
Sobald eine Anweisung nicht nicht mehr auf Result bezieht (also kein Bezeichner mit einem . anfängt) ist der use-Bezug hinfällig und ungültig.

---

Wenn, dann würde ich mir so etwas wünschen.
Das wäre nachvollziehbar und einfach ein besseres "with".

Alle Klassen umzubauen um Anweisungen mit einem Punkt starten zu können wäre mir zu aufwendig und bezüglich der Debugbarkeit halte ich das auch nicht für hilfreich.
Außerdem sollten Funktionen für die Logik da sein und nicht für das Code-Styling.

Wenn ich eine Methode TPerson.SetIsNice(True) habe, dann sollte die möglicherweise für die Validierung ein Accept zurück geben und nicht die Klasse.

Also ich brauche ein fluent interface eher nicht und würde eher ein anderes Sprachfeature wünschen, um Codekürzungen zu erreichen. Da wäre ich dann dabei.

[Schokohase]

@stahli

Das Besondere am Fluent Interface ist kein Ersatz für

Delphi-Quellcode:

Result := CreateSomeInterface;
Result.DoSomething('withParameter');
Result.DoSomethingOther;
Result.ConvertEverythingTo;

sondern das hier

Delphi-Quellcode:

ResultA := CreateSomeInterface; // IFoo
ResultB := ResultA.DoSomething('withParameter'); // IBar
ResultC := ResultB.DoSomethingOther; // IOther
ResultD := ResultC.ConvertEverythingTo; // string

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.

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

[Mavarik]

Es gibt mehrere Gründe den Sourcecode "so" zu schreiben.

Beispiel SQL:

Delphi-Quellcode:

  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);

Wie üblich die {} , 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:

    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}
    {}                        ;

Ich empfehle hierzu mein CodeRage Video. Auch wenn hier leider noch von Fluid und nicht Fluent gesprochen wird. // Danke Stefan hab es in ALLEN Sourcen renamed...

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:

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);

schreiben kann..

Grüsse Mavarik

[dummzeuch]

Zitat von HolgerX:

Hmm..

Zitat von dummzeuch:

Zitat von peterbelow:

Stell Dir mal vor, Du mußt sowas debuggen, dann ist es nicht mehr so schön...

Einfach vernuenftig formatieren ...

Delphi-Quellcode:

Result := CreateSomeInterface
  .DoSomething('withParameter')
  .DoSomethingOther
  .ConvertEverythingTo

... und schon ist das kein Problem mehr. Und lesbarer ist es (IMHO) auch.
(Ob der OP das dann allerdings immernoch "schön" findet?).

So etwas ist immer gefährlich....

Was ist, wenn es beim '.DoSomething('withParameter')' kracht oder etwas geliefert wird, was in '.DoSomethingOther' zur Exception führt?

Wenn ich das in einer Zeile schreibe, wie kann ich dann im Debugger erkennen, wo es geknallt hat?

In der Regel ja. Deshalb die Formatierung mit einem Aufruf pro Zeile.
Zum Debuggen wäre natürlich eine Variable einfacher:

Delphi-Quellcode:

Result := CreateSomeInterface;
Result := Result.DoSomething('withParameter');
Result := Result.DoSomethingOther;
Result := Result.ConvertEverythingTo;

Aber das versaut das "schöne" dann komplett.

(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.

[Uwe Raabe]

Zitat von dummzeuch:

Zum Debuggen wäre natürlich eine Variable einfacher

Macht sich auch besser im Watch-Fenster oder bei Ctrl-F7.

Es ist halt immer ein Kompromiss zwischen "schön" bzw. lesbar und leichter zu debuggen.

Zitat von dummzeuch:

Wenn nicht, muesste man auch noch jede Menge Variablen deklarieren, was noch viel mehr Tipperei ist.

Na ja, unter Rio hält sich das ja noch in Grenzen:

Delphi-Quellcode:

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;

Ach ja, früher galt with auch als richtig cool, weil man da soviel Tipperei spart.

[stahli]

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.

[Mavarik]

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

[Uwe Raabe]

Zitat von mavarik:

bietet es sich natürlich an, einen unittest zu schreiben, dann braucht man i.d.r. Auch nicht debuggen oder eher selten.