case .. of kann kein break - Gibt es dafür einen rationalen Grund?

[Rollo62]

Hallo zusammen,

! Das ist kein Feature-Request.

Ich möchte nur verstehen, warum man in der Delphi/Pascal Sprache nicht ein einfaches case - break vorgesehen hat?

Delphi-Quellcode:

  case LMyVariable of
     TMyVariable.One: X := 1;
     TMyVariable.Two      : begin

                                Mache1;

                                if MyCondition then
                                begin
                                    Mache2;
                                end;

                            end;
     TMyVariable.ThreeBlue: begin

                                Mache1;

                                if not MyCondition then
                                begin
                                    break;                 //<== DAS GIBT ES LEIDER NICHT =================
                                    goto CaseBreakLabel;   //<== Wäre die einzige rationale Verwendung von goto, mach ich aber trotzdem nicht 
                                end;

                                Mache2;

                            end;
     else
                            begin
                            end;
  end;
  
CaseBreakLabel:

  HierGehtsWeiter;

Ich möchte jetzt nicht unbedingt über die Funktion von break oder goto diskutieren.
Ich möchte nur verstehen, warum es die Design-Entscheidung bei Pascal gab, dies nicht reinzusetzen.

Da es bereits case-break in anderen Sprachen (C) gab, gehe ich davon aus, dass dies bei Pascal nicht einfach nur "vergessen" wurde.

Dafür muss es doch einen rationalen Grund für die Entscheidung gegeben haben.
Kennt den vielleicht jemand?

[DeddyH]

War es in C nicht so, dass ab dem passenden case-Label alle folgenden Fälle auch abgearbeitet werden und man deswegen das break braucht, wenn man dieses Verhalten nicht will? Falls das so stimmt, dann wird das break in Pascal gar nicht gebraucht, da ja automatisch "gebreakt" wird. Mangels C-Compiler kann ich das gerade nicht ausprobieren, habe das aber so noch in Erinnerung (allerdings sind meine letzten C-Versuche auch schon wieder 20 Jahre her).

[Klaus01]

in C muss ein break verwendet werden, weil sonst die nachfolgenden Anweisungen (in dem switch Konstrukt) auch abgearbeitet werden.

In pascal ist das nicht notwendig.

Viele Grüße
Klaus

[Rollo62]

Ja das stimmt.
Ist das denn ein Grund keinen Exit-Mechanismus vorzusehen?

Es geht ja um das vorzeitige Verlassen eines Scopes.
Entspricht das etwa irgendwie nicht den guten Gepflogenheiten?

Es gibt ja ein anderes "AntiPattern", in Methoden - ein Guard ( Exit; ) um vorzeitig anzubrechen.

Delphi-Quellcode:

function MyFunc( AParam : Integer ) : Boolean;
begin
    if AParam < 0 then
    begin 
        Result := False;
        Exit;  //<== GUARD - sichere vor falschen Parametern ============
    end;

    // Hier kann ich munter mit dem Parameter arbeiten, ohne dass die Funktion abraucht 
    AParm := AParam * 100;
    ...

    Result := True;
end;

Ich benutze das "AntiPattern" sehr gerne, weil es eben irrsinnig tiefe if then Verschachtelungen wunderbar einfach und lesbar auflösen kann.
Für Sprachpuristen kommt das glaube ich aber nicht in Frage.

Es scheint mir so das gleiche Argument zu sein.
Das geht vielleicht alles in die Richtung: "break, continue, Exit ist auch nur ein GOTO".

Könnte das der wahre Grund dahinter sein?

[DeddyH]

Wozu etwas einbauen, was niemals gebraucht wird? Das Verhalten eines Switch-Case ist in C und Pascal wie gesagt unterschiedlich, deshalb macht ein break in C Sinn, in Pascal aber nicht.

[Uwe Raabe]

Standard Pascal nach Jensen/Wirth kennt dieses Break gar nicht. Eingeführt wurde es um Schleifen vorzeitig bzw. unabhängig von der Schleifenbedingung abzubrechen. Ein Verlassen des Scopes mit Exit gibt es (neben Goto, geht aber nicht immer) nur bei Methoden, Prozeduren und Funktionen. Das case-Konstrukt gehört in keine dieser Kategorien.

Ich würde auch kein break innerhalb des case haben wollen. Dazu benutze ich es zu gern zum Abbruch einer darum liegenden Schleife.

[Rollo62]

Ja, ist alles richtig.

Aber welchen Grund gibt es, das break NICHT in case scopes zu benutzen?
Vielleicht verstößt das gegen irgendein Informatik-Grundgesetz, das ich nicht kenne. (Die Würde des Scopes ist unantastbar :-D)

Aber im Ernst:
Es könnte was mit den Ablaufpfaden innerhalb von Scopes zu tun haben.

[Der schöne Günther]

Das hat doch nichts mit Scopes zu tun - Ein break verlässt eine Schleife. Ein case ist keine Schleife. Ich käme auch nie auf die Idee, ein „if/else“ mit break verlassen zu wollen.

[Sinspin]

Zitat:

Zitat von Rollo62 (Beitrag 1536480)

Ist das denn ein Grund keinen Exit-Mechanismus vorzusehen?

Wozu denn? Es wird nicht gebaucht.
In Pascal ist ein CASE eindeutig! Es wird nur der Block ausgeführt für den die Bedingung passt. Warum sollte man da extra was hinschreiben müssen was keinen Effekt hat?

Oder meinst Du das andersrum? Suchst Du nach einem CASE was ein Break braucht?
Warum? Was gedenkst du zu implementieren was dieses Verhalten unbedingt erforderlich machen würde?

[hannsg]

Die "reine Lehre" sagt wohl, dass jeder Block nur genau einen Eingang und genau einen Ausgang haben darf. Daher ist sowas im ursprünglichen Pascal nicht enthalten...

Gruß, Meik

[Sherlock]

Zitat:

Zitat von Der schöne Günther (Beitrag 1536484)

Das hat doch nichts mit Scopes zu tun - Ein break verlässt eine Schleife. Ein case ist keine Schleife. Ich käme auch nie auf die Idee, ein „if/else“ mit break verlassen zu wollen.

Damit dürfte des Kopfes Nagel getroffen worden sein. Andererseits...if-Schleife...hmmmm :stupid:

[Rollo62]

Zitat:

Zitat von hannsg (Beitrag 1536486)

Die "reine Lehre" sagt wohl, dass jeder Block nur genau einen Eingang und genau einen Ausgang haben darf. Daher ist sowas im ursprünglichen Pascal nicht enthalten...

Gruß, Meik

Das bleibt doch auch so.
Aber ja, es gibt dann versciedene Pfade.
Die gibt es durch if then else, case usw. auch schon.

Und ja, "break" ist in Pascal für Schleifen da.
Vermutlich sollte ich im C-Formum mal danach fragen.

Zitat:

Zitat von Uwe Raabe (Beitrag 1536482)

Standard Pascal nach Jensen/Wirth kennt dieses Break gar nicht. Eingeführt wurde es um Schleifen vorzeitig bzw. unabhängig von der Schleifenbedingung abzubrechen. Ein Verlassen des Scopes mit Exit gibt es (neben Goto, geht aber nicht immer) nur bei Methoden, Prozeduren und Funktionen. Das case-Konstrukt gehört in keine dieser Kategorien.

Ja, ein Exit verlässt eine Methode/Prozedur/Funktion, also auch den Scope eben dieser.
Na gut, wenn ich innerhalb einer Methode extra Scopes mit begin ... end aufmache, dann verlässt ein Exit immer noch die ganze Methode.

Du stimmst mir hoffentlich zu, das innerhalb eines cases auch ein "Scope" existiert.
Klar kann ich da auch mit Exit; raus.

Zitat:

Zitat von Uwe Raabe (Beitrag 1536482)

Ich würde auch kein break innerhalb des case haben wollen. Dazu benutze ich es zu gern zum Abbruch einer darum liegenden Schleife.

Das Problem hat man in C natürlich auch.

Die meisten Erklärungen bis jetzt sind aber nur persönliche Befindlichkeiten oder Abneigungen, aber bis jetzt kein echter Informatik-lastiger Grund,
wieso ein frühzeitiger Abbruch eines case ... of Scopes irgendwie schädlich sein könne.
Der Beweis wäre das es mit goto geht, wahrscheinlich muss ich bei den Gründen nach den Abneigungen gegen goto suchen (Spagetti-Code). :stupid:

[himitsu]

Nochmal zusammengefasst:

• CASE im Pascal ist eine JumpList, welche in die einzelnen CASEs springt, nur den Einen ausführt und automatisch abbricht (zum Ende springt).
• In C-Sprachen wird beim CASE an den Anfang des Gewünschten gesprungen und ab da wird ALLES ausgeführt, es sei denn mit BREAK wird abgebrochen..
• BREAK im Pascal/Delphi bricht nur Schleifen ab, also FOR, WHILE und REPEAT.

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1536474)

Delphi-Quellcode:

  case LMyVariable of
     TMyVariable.One: X := 1;
     TMyVariable.Two      : begin

                                Mache1;

                                if MyCondition then
                                begin
                                    Mache2;
                                end;

                            end;
     TMyVariable.ThreeBlue: begin

                                Mache1;

                                if not MyCondition then
                                begin
                                    break;                 //<== DAS GIBT ES LEIDER NICHT =================
                                    goto CaseBreakLabel;   //<== Wäre die einzige rationale Verwendung von goto, mach ich aber trotzdem nicht 
                                end;

                                Mache2;

                            end;
     else
                            begin
                            end;
  end;
  
CaseBreakLabel:

  HierGehtsWeiter;

In deinem Beispiel wäre das break als Scope-Exit des case-Statements ja auch willkürlich gewählt. Man könnte es auch so interpretieren, dass es ein Exit des then-Zweigs oder des begin-end Block des case Labels ist (was in diesem Fall wiederum äquivalent zum case wäre). Irgendwo muss dann aber beim break der Scope definiert sein, der damit verlassen wird. Bei einer Schleife ist das noch ersichtlich: es ist die innerste Schleife im aktuellen Scope. Bei der Vielzahl möglicher Scopes in Pascal wäre das doch total unübersichtlich.

Wie schon gesagt, ich bin mit der Definition ein break bricht die innerste Schleife im Scope ab ganz zufrieden. Alles darüber hinaus wäre nicht nur schwerer zu durchschauen, sondern kann auch bei einer simplen Änderung des Codes völlig anders verlaufen (z.B. wenn man das

Delphi-Quellcode:

if not Condition then...

mit einem weiteren case-Konstrukt oder einer Schleife umschließt). Das ist ja schon jetzt bei Schleifen zu beachten. Ohne eine syntaktische Möglichkeit den zu verlassenden Scope anzugeben wäre das nur sehr schwer zu warten.

[himitsu]

Zitat:

Delphi-Quellcode:

                                if not MyCondition then
                                begin
                                    break; //<== DAS GIBT ES LEIDER NICHT =================
                                    goto CaseBreakLabel; //<== Wäre die einzige rationale Verwendung von goto, mach ich aber trotzdem nicht
                                end;

                                Mache2;

Delphi-Quellcode:

                                if MyCondition then
                                begin
                                    Mache2;
                                end;

Erstmal kein Break notwendig,
erspart auch gleich die unnötige Negierung
und man erkennt sofort, dass es eigentlich identisch mit Two ist. :stupid:

[himitsu]

Man könnte vielleicht mal einen Feature-Request stellen, für ein neues CASE, welches c-iger arbeitet,
also ohne Implizites und dafür optional mit manuellen BREAKs.

[Rolf Frei]

Ich glaube die lachen dich dann für den Feature Request aus. Komplett unnötig.

[QuickAndDirty]

Rollo62 warum kann ich den Scope von einer IF THEN Anweisung nicht mit break verlassen?
WAAAAARUMMMM?

Delphi-Quellcode:

For var i:integer := low(Werte) to High(Werte) do
Begin
  case Werte[i] of
    TWert.wGut: DoWert_gut;
    TWert.wSchlecht: DoWert_schlecht;
    TWert.wVerseucht:
      Begin
        Showmessage('Alles unbraucbar!');
        break; //Welches verhalten erwartest du hier?
      end;
    else
      DoWert_unspezifisch;
  end;
end

[freimatz]

Die Lehre der Strukturierte Programmierung :lol:

[Rollo62]

Zitat:

Zitat von Uwe Raabe (Beitrag 1536491)

Irgendwo muss dann aber beim break der Scope definiert sein, der damit verlassen wird.

Ja gut, wie gesagt, bei C gibt es das gleiche Problem, dass ein break nicht für eine außenliegende Schleife zuständig ist.
Oder besser gesagt, dass break wäre in diesem Fall IMMER für das case .. of zuständig, und nicht für die außenliegende Schleife.

Ok, zumindest könnte man sagen, dass dies ein halbwegs plausibler Grund gegen break im case wäre.

Man könnte aber auch so argumentieren:

Delphi-Quellcode:

 case LMyVariable of
     TMyVariable.One: X := 1;  //<= HIER ist de facto ein "BREAK", Ende des case statements

     TMyVariable.ThreeBlue: begin
                                Mache1;

                                if not MyCondition then
                                begin
                                    break; //<= HIER soll es kein "BREAK", Ende des case statements geben
                                end;

                                Mache2;

                            end;  //<= HIER ist de facto ein "BREAK", Ende des case statements
  end;

Zitat:

Zitat von himitsu (Beitrag 1536493)

Man könnte vielleicht mal einen Feature-Request stellen ...

! Ich hatte explizit im Anfage gesagt, dass ich keinen Feature-Request möchte.
Ich möchte nur die Gründe kennen, die dagegen sprechen.

Da hätte ich an Pfade oder Sprungoptimierungen gedacht, aber es scheint nur philosophische Gründe dagegen zu sprechen.
Eingeschlossen, wie oben, dass ein break dann das break einer außenliegenden Schleife wegnehmen würde.

Ok, ok, belassen wir es dabei.
Ich brauche keine alternativen Vorschläge dazu, ich hatte ja schon erklärt, dass ich gerne Guards einsetze,
statt tiefverschachtelter, unübersichtlicher if-then-else.

Wahrscheinlich macht es dann sowieso Sinn statt "begin end;" im case zu haben, besser eine spezifische Case-Funktion aufzurufen.

[Rollo62]

Abschliessend vielleicht noch was ChatGPT dazu sagt:

Zitat:

- Philosophie von Strukturierter Programmierung: Pascal wurde mit einem starken Fokus auf strukturierte Programmierung und Einfachheit im Design entwickelt. Wirth wollte eine Sprache schaffen, die leicht zu lehren und zu verstehen ist, insbesondere für Studenten und Entwickler, die sich auf die Algorithmen und nicht auf komplexe Sprachkonstrukte konzentrieren sollen. Die case-Anweisung wurde so entworfen, dass sie klar und unmissverständlich ist, ohne die Möglichkeit für unerwartete Sprünge oder das Verlassen von Anweisungsblöcken, die zu schlecht lesbarem Code führen könnten.

Vermeidung von Kontrollfluss-Komplexität: Die break-Anweisung in Sprachen wie C erlaubt es, den normalen Fluss einer Schleife oder eines Schalters (Switch) abrupt zu unterbrechen. Dies kann zu "Spaghetti-Code" führen, bei dem der Kontrollfluss schwer nachzuvollziehen ist. Indem Pascal diese Option ausschließt, fördert es eine klarere, linearere Codestruktur.

Geschichtliche Entwicklung: Zur Zeit der Entwicklung von Pascal gab es bereits andere Programmiersprachen wie ALGOL, die ähnliche Kontrollstrukturen ohne break nutzten. Wirths Entscheidung, break nicht zu implementieren, reflektiert möglicherweise auch eine Präferenz für die strengeren Kontrollflusskonzepte von ALGOL.

Fehlervermeidung: Durch das Fehlen einer break-Anweisung werden Fehler vermieden, die durch das versehentliche Überspringen des Rests eines Schaltblocks entstehen könnten, was in komplexen Switch-Anweisungen in C häufig Probleme verursacht.

Wurde im Prinzip ja alles schon gesagt, hier nochmal schön zusammengefasst.

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1536499)

ich hatte ja schon erklärt, dass ich gerne Guards einsetze,
statt tiefverschachtelter, unübersichtlicher if-then-else.

In dem Fall könnte man den Code der jeweiligen case-labels in separate Methoden oder lokale Prozeduren auslagern. Dort kannst du dann problemlos die Guards einsetzen.

[Rollo62]

Zitat:

Zitat von Uwe Raabe (Beitrag 1536502)

Zitat:

Zitat von Rollo62 (Beitrag 1536499)

ich hatte ja schon erklärt, dass ich gerne Guards einsetze,
statt tiefverschachtelter, unübersichtlicher if-then-else.

In dem Fall könnte man den Code der jeweiligen case-labels in separate Methoden oder lokale Prozeduren auslagern. Dort kannst du dann problemlos die Guards einsetzen.

Zitat:

Wahrscheinlich macht es dann sowieso Sinn statt "begin end;" im case zu haben, besser eine spezifische Case-Funktion aufzurufen.

Das meinte ich, war vermutlich zu sperrig formuliert :-D

[TSchnuckenbock]

Rollo62 sprach ja in Beitrag #4 von "Antipattern". Da dachte, schau mal nach....

https://de.wikipedia.org/wiki/Anti-Pattern

Für den Nachmittag vorm Feiertag vielleicht genau richtig zum Lesen.

Das "Antipattern", am Anfang einer Methode mit if-then und einem exit dann rauszuspringen setze ich übrigens auch gerne ein.

Zum Thema: Ein break im Case-Konstrukt habe ich noch nie vermisst.

[Rollo62]

Allerdings, schöne zusammengefasst auf der Seite.

Zitat:

Zitat von TSchnuckenbock (Beitrag 1536504)

Das "Antipattern", am Anfang einer Methode mit if-then und einem exit dann rauszuspringen setze ich übrigens auch gerne ein.

Da bin ich mittlerweile ganz anderer Meinung.
Denn ich nutze das "GUARD" Pattern sehr ausgiebig, was ich auch mit "negative Logic" benenne.
Also statt immer nur bei positiv ins nächste if-then verzweigen, erzeugt oft sehr unübersichtliche Strukturen.

Während ein "GUARD" mit "negativer Logik" am Anfang einer Methode diese sicher absichert und
im Folgenden die eigentlich wichtigen Abläufe sehr sauber darstellt.

Das habe ich zum Beispiel auch in anderen Sprachen sehr positiv wahrgenommen, dass dies die Methoden ordentlich aufräumen kann.

Am Besten mal selber eine zeitlang ausprobieren, denn der positive Effekt stellt sich schnell ein.

Nicht alle "AntiPattern" müssen direkt immer in der Hölle enden :-D

[himitsu]

außen ein Try-Except drumrum und dann ABORT statt BREAK. :duck:

[Rollo62]

Zitat:

Zitat von himitsu (Beitrag 1536507)

außen ein Try-Except drumrum und dann ABORT statt BREAK. :duck:

Jesus H. Christ :shock:

[Jasocul]

Warum seid ihr so versessen auf diese Guard am Anfang einer Methode?
Entweder es ist eine einfache Prüfung, dann hat man höchstens eine Ebene mehr in der Verschachtelung oder es sind viele Prüfungen erforderlich, dann macht man eine Function davon und hat wieder nur eine Ebene mehr. Ich habe dieses Anti-Pattern noch nie gebraucht und ich halte meinen Code für sehr gut lesbar. Meine Kollegen haben sich zumindest noch nie darüber beschwert und ich bezweifle, dass die Angst vor mir haben. :lol:

Zum Break im Case:
Das ist Delphi/Pascal und nicht C. Niklaus Wirth hat es so definiert. Dass es auch anders geht, steht außer Frage. Ich sehe aber keinen ernsthaften Grund, warum das notwendig sein sollte. Da gibt es andere Einschränkungen im Case, die mich mehr nerven. Z.B. die Beschränkung auf ordinale Typen.

[himitsu]

Wobei das auch schon im Basic so war (ohne Break), sowie auch COBOL (außer dass dort das CASE noch EVALUATE hieß), Algol und anderen Delphi/Pascal-Vorfahren.
Also eigentlich war es garnicht seine Idee.

Joar, Strings wären auch mal was.

Delphi-Quellcode:

uses System.StrUtils, Vcl.Dialogs;
type TTheCase = (blubb, blob, wuppdi);
const cTheCase: array[TTheCase] of string = ('blubb', 'blob', 'wuppdi');

procedure TForm1.FormCreate(Sender: TObject);
begin
  var S := InputBox(Application.Title, 'Was: ' + string.join(' ', cTheCase), 'mähhh');
  case TTheCase(IndexStr(S, cTheCase)) of
    blubb, blob: ShowMessage('Juhu: ' + S);
    wuppdi: ShowMessage('Hihooo: ' + S);
    else ShowMessage('Nööö: ' + S)
  end;
end;

[Rollo62]

Zitat:

Zitat von Jasocul (Beitrag 1536537)

Entweder es ist eine einfache Prüfung, dann hat man höchstens eine Ebene mehr in der Verschachtelung oder es sind viele Prüfungen erforderlich, ...

Wenn man meint es sei nur Versessenheit, dass man zwischen "einfach" und "komplex" auch noch mögliche Zwischenstufen sieht und ich mir dieses sogenannte "AntiPattern" einfach dafür offen halte,
dann kann ich ja genauso mit "Versessenheit" argumentieren, wenn man das ums Verrecken niemals nicht benutzen will :lol:

Ob Du die Komplexität nun hinter Funktionen versteckst, oder nicht, das Ergebnis bleibt das Gleiche.
Jedenfalls sehe ich durch negative Logik eine deutliche Verbesserung der Lesbarkeit und Code-Verständlichkeit, als wenn ich erst in zig Funktionen reinspringen und nachsehen müsste.

[Jasocul]

Zitat:

Zitat von Rollo62 (Beitrag 1536581)

Ob Du die Komplexität nun hinter Funktionen versteckst, oder nicht, das Ergebnis bleibt das Gleiche.

Völlig korrekt, aber mit dem Argument könnte man auch rechtfertigen, dass man Variablen einfach durchnummerieren kann oder jede Form von Styleguide ignorieren.

Zitat:

Zitat von Rollo62 (Beitrag 1536581)

Jedenfalls sehe ich durch negative Logik eine deutliche Verbesserung der Lesbarkeit und Code-Verständlichkeit, als wenn ich erst in zig Funktionen reinspringen und nachsehen müsste.

Und ich sehe in einer Guard eine deutliche Verschlechterung der Lesbarkeit. Insbesondere, wenn dieser ein paar Zeilen der eigentlichen Prozedur wegnimmt, bevor man zum wesentlichen Code kommt. Ich habe leider schon Gurads gesehen, die über 20 Zeilen lang waren.
Wenn man für die Verständlichkeit in die Funktionen reinspringen muss, dann sollte man vielleicht eher darüber nachdenken, den Funktionen einen brauchbaren Namen zu geben. Ich schaue in diese Funktionen übrigens nur rein, wenn etwas nicht funktioniert.

Aber ich denke, dass man hier durchaus unterschiedlicher Meinung sein darf. Mein Code wird halt anders aussehen, als deiner ;-)

[himitsu]

du darfst auch gern eine $REGION drumrummachen, dann isses nur eine Zeile und du siehst auch ab wo der eigentliche Code beginnt.

[Rollo62]

Zitat:

Zitat von Jasocul (Beitrag 1536616)

Aber ich denke, dass man hier durchaus unterschiedlicher Meinung sein darf. Mein Code wird halt anders aussehen, als deiner ;-)

Ja das sehe ich auch so, ich verstehe ja auch all die Argumente für und wider.
Nur werden oft die Argumente wider nicht immer ernsthaft beleuchtet, das finde ich etwas schade.

Ich sehe insbesondere, dass es vielleicht Problemstellungen geben kann, die nicht immer nur die "reine Lehre" nach Schema F erforderlich machen.
Was ich zum Beispiel meine ist, dass wenn Du meistens mit festen, schön separierbaren Algorithmen arbeiten kanst,
diese zu 100% wasserdicht und vorhersagbar austesten kannst, dann bin ich ja voll und ganz auf deiner Seite.

Es gibt aber aus meiner Sicht auch viele Anwendungen die von sehr vielen Parametern und sehr stark von völlig unvorhersagbaren Ereignissen beeinflusst werden kann, insbesondere duch externe Hardware, Systemereignisse oder auf verschiedenen Plattformen usw.
Wie zum Beispiel, gerade war ein Sensor noch ansprechbar und in der nächsten Millisekunde ist der komplett weggegrätscht.
An diesen Fragestellungen befinde ich mich leider oft und da mache ich lieber einen Guard mehr als zu wenig, egal was Andere darüber denken.
Lieber safe than sorry :-D

[Uwe Raabe]

Ein Variation des Guard-Patterns, welches im Wesentlichen beide Ansätze kombiniert, ist die Teilung in eine guarded und eine unguarded Methode. Die guarded Methode enthält dann ausschließlich die Guards gefolgt von einem Aufruf der unguarded Methode (je nach Geschmack am Schluss oder in einem mehr oder minder komplexen

Delphi-Quellcode:

if

). Damit ersetzt die guarded Methode die Auslagerung der Guards in eine separate Funktion. Mit der unguarded Methode erhält man aber zusätzlich eine performantere Möglichkeit für die Fälle, bei denen die Validität der Parameter bereits geprüft oder anderweitig sichergestellt ist.

Eine separate Guard-Funktion ist aber in jedem Fall eine Überlegung wert, wenn Parameter-Sätze an mehreren Stellen auf die gleiche Validität geprüft werden.