Ist dies ein gutes Muster: Ersetzen einer langen Funktion durch eine Reihe von Lambdas?

Ich bin kürzlich auf die folgende Situation gestoßen.

class A{
public:
    void calculate(T inputs);
}

Erstens Astellt es ein Objekt in der physischen Welt dar, was ein starkes Argument dafür ist, die Klasse nicht aufzuteilen. Nun calculate()stellt sich heraus, dass es eine ziemlich lange und komplizierte Funktion ist. Ich sehe drei mögliche Strukturen dafür:

• Schreiben Sie es als Textwand - Vorteile - alle Informationen sind an einem Ort
• Schreiben Sie privateHilfsfunktionen in die Klasse und verwenden Sie sie im calculateHauptteil - Nachteile - der Rest der Klasse kennt / kümmert sich / versteht nicht um diese Methoden

• schreibe wie calculatefolgt:

  void A::calculate(T inputs){    
      auto lambda1 = () [] {};    
      auto lambda2 = () [] {};    
      auto lambda3 = () [] {};
  
      lambda1(inputs.first_logical_chunk);
      lambda2(inputs.second_logical_chunk);
      lambda3(inputs.third_logical_chunk);
  }
  

Kann dies als eine gute oder schlechte Praxis angesehen werden? Zeigt dieser Ansatz irgendwelche Probleme? Alles in allem sollte ich dies als einen guten Ansatz betrachten, wenn ich wieder mit der gleichen Situation konfrontiert bin?

BEARBEITEN:

class A{
    ...
public:
    // Reconfiguration of the algorithm.
    void set_colour(double colour);
    void set_density(double density);
    void set_predelay(unsigned long microseconds);
    void set_reverb_time(double reverb_time, double room_size);
    void set_drywet(double left, double right);
    void set_room_size(double value);;

private:
    // Sub-model objects.
    ...
}

Alle diese Methoden:

• einen Wert bekommen
• Berechnen Sie einige andere Werte, ohne state zu verwenden
• Rufen Sie einige der "Submodell-Objekte" auf, um ihren Status zu ändern.

Mit Ausnahme set_room_size()dieser Methoden wird der angeforderte Wert einfach an Unterobjekte übergeben. set_room_size()Auf der anderen Seite werden einige Bildschirme mit undurchsichtigen Formeln angezeigt, und dann wird (2) ein halber Bildschirm zum Aufrufen von Unterobjektsetzern ausgeführt, um die verschiedenen erhaltenen Ergebnisse anzuwenden. Deshalb habe ich die Funktion in zwei Lambdas aufgeteilt und am Ende der Funktion aufgerufen. Hätte ich es in logischere Stücke aufteilen können, hätte ich mehr Lambdas isoliert.

Unabhängig davon besteht das Ziel der aktuellen Frage darin, festzustellen, ob diese Denkweise fortbestehen soll oder ob sie allenfalls keinen Mehrwert bringt (Lesbarkeit, Wartbarkeit, Debug-Fähigkeit usw.).

Nein, dies ist im Allgemeinen kein gutes Muster

Sie zerlegen eine Funktion mit Lambda in kleinere Funktionen. Es gibt jedoch ein viel besseres Werkzeug, um Funktionen aufzubrechen: Funktionen.

Lambdas funktionieren, wie Sie gesehen haben, aber sie bedeuten viel, viel, viel mehr als nur die Aufteilung einer Funktion in lokale Teile . Lambdas machen:

• Verschlüsse. Sie können Variablen im äußeren Bereich innerhalb des Lambda verwenden. Das ist sehr mächtig und sehr kompliziert.
• Neuzuweisung. Während Ihr Beispiel die Zuweisung erschwert, muss man immer darauf achten, dass Code jederzeit Funktionen austauschen kann.
• Erstklassige Funktionen. Sie können eine Lambda-Funktion an eine andere Funktion übergeben, indem Sie etwas tun, das als "funktionale Programmierung" bezeichnet wird.

In dem Moment, in dem Sie Lambdas in den Mix aufnehmen, muss der nächste Entwickler, der sich den Code ansieht, alle diese Regeln sofort mental laden, um zu sehen, wie Ihr Code funktioniert. Sie wissen nicht, dass Sie nicht alle diese Funktionen nutzen werden. Dies ist im Vergleich zu den Alternativen sehr teuer.

Es ist wie mit einer Hinterhacke, um Ihre Gartenarbeit zu tun. Sie wissen, dass Sie damit nur kleine Löcher für die diesjährigen Blumen graben, aber die Nachbarn werden nervös.

Bedenken Sie, dass Sie Ihren Quellcode nur visuell gruppieren müssen. Dem Compiler ist es eigentlich egal, dass Sie Dinge mit Lambdas belegen. Tatsächlich würde ich erwarten, dass der Optimierer alles, was Sie gerade beim Kompilieren getan haben, sofort rückgängig macht. Sie sind nur für den nächsten Leser da (Vielen Dank, auch wenn wir uns in Bezug auf die Methodik nicht einig sind! Code wird weitaus häufiger gelesen als geschrieben!). Alles, was Sie tun, ist die Gruppierungsfunktionalität.

• Funktionen, die lokal innerhalb des Quellcode-Streams platziert sind, würden genauso gut funktionieren, ohne Lambda aufzurufen. Auch hier ist alles, was zählt, dass der Leser es lesen kann.
• Die Kommentare oben in der Funktion lauten "Wir teilen diese Funktion in drei Teile", gefolgt von langen Zeilen // ------------------zwischen den einzelnen Teilen.
• Sie können auch jeden Teil der Berechnung in einen eigenen Bereich einordnen. Dies hat den Vorteil, dass zweifelsohne sofort bewiesen wird, dass es keine variable Aufteilung zwischen den Teilen gibt.

BEARBEITEN: Nachdem ich Ihre Bearbeitung mit Beispielcode gesehen habe, neige ich dazu, dass die Kommentarnotation die sauberste ist und Klammern verwendet werden, um die in den Kommentaren angegebenen Grenzen durchzusetzen. Wenn jedoch eine der Funktionen in anderen Funktionen wiederverwendet werden kann, würde ich empfehlen, stattdessen Funktionen zu verwenden

void A::set_room_size(double value)
{
    {
        // Part 1: {description of part 1}
        ...
    }
    // ------------------------
    {
        // Part 2: {description of part 2}
        ...
    }
    // ------------------------
    {
        // Part 3: {description of part 3}
        ...
    }
}

Ich denke, Sie haben eine schlechte Annahme gemacht:

Erstens repräsentiert A ein Objekt in der physischen Welt, was ein starkes Argument dafür ist, die Klasse nicht aufzuteilen.

Ich bin damit nicht einverstanden. Wenn ich zum Beispiel eine Klasse hätte, die ein Auto repräsentiert, würde ich sie definitiv aufteilen wollen, weil ich sicher möchte, dass eine kleinere Klasse die Reifen repräsentiert.

Sie sollten diese Funktion in kleinere private Funktionen aufteilen. Wenn es wirklich vom anderen Teil der Klasse getrennt zu sein scheint, kann dies ein Zeichen dafür sein, dass die Klasse getrennt werden sollte. Natürlich ist es schwer zu sagen, ohne ein explizites Beispiel.

In diesem Fall sehe ich den Vorteil der Verwendung von Lambda-Funktionen nicht wirklich, da der Code dadurch nicht wirklich sauberer wird. Sie wurden entwickelt, um die Programmierung funktionaler Stile zu unterstützen, aber das ist nicht das Gegenteil.

Was Sie geschrieben haben, ähnelt ein wenig geschachtelten Funktionsobjekten im Javascript-Stil. Was wiederum ein Zeichen dafür ist, dass sie eng zusammengehören. Sind Sie sicher, dass Sie keine separate Klasse für sie machen sollten?

Zusammenfassend denke ich nicht, dass dies ein gutes Muster ist.

AKTUALISIEREN

Wenn Sie keine Möglichkeit sehen, diese Funktionalität in einer aussagekräftigen Klasse zu kapseln, können Sie dateibezogene Hilfsfunktionen erstellen, die nicht zu Ihrer Klasse gehören. Dies ist schließlich C ++, OO-Design ist kein Muss.