Commit 1dc61fd

linear in dieser Reihenfolge erfolgen sollen. Dies ist technisch sinnvoll, soll aber auch eine Abbildbarkeit eines Softwareprozesses auf eine abstraktes Prinzip unterstützen, das dem Prinzip *Ursache* und *Wirkung* nahekommt.

{: #einleitung}

Die Sprache PHP ist eng mit dem EVA-Prinzip verknüpft, weil der übliche Spracheinstieg eng mit der Funktion von PHP als dynamische Ausgabe verknüpft ist:

Im Beispiel wirkt PHP größtenteil als Templating-Funktion. Das bedeutet, in ein statisches (Text-)Konstrukt (Template) wird ein dynamischer Inhalt „eingebaut“. Im Prinzip ist das auch die Hauptaufgabe von PHP - die Sprache wurde entworfen, um dynamisch HTML-Dokumente zu generieren. PHP ist jedoch auch eine vollwertige Programmiersprache. Wir könnten also innerhalb unseres Dokuments Werte berechnen, Dateisystemoperationen durchführen o.ä. In diesem Fall wird unser Template schnell fragmentiert, da die Anzahl von Codezeilen der Verarbeitungs-Komponente stark zunimmt. Auch stellt sich die Frage, an welche Stelle diese Verarbeitung gehört. Praktisch gesehen natürlich vor die Ausgabe (das ist logisch), das EVA-Prinzip geht allerdings weiter und definiert den richtigen Platz dafür vor jegliche Ausgabe.

{: #client-server-prinzip}

Um dies weiter zu betrachten, müssen wir uns kurz das Prinzip von Webkommunikation ansehen. Auf einen Request des Client erfolgt die Antwort in Form unseres PHP-generierten Dokuments. Auf einer tieferen Ebene (vgl. OSI-Modell) wird neben den offensichtlichen Textinhalten aber auch eine Reihe von Meta-Informationen versendet: die sogenannten HTTP-Header. Diese Header können auch durch PHP gesetzt werden. Nicht gesetzte Header produziert der Webserver eigenständig. Für das EVA-Prinzip relevant ist vor allem, dass dies vor jeglicher Textausgabe erfolgt. Das bedeutet, der Webserver erkennt eine Textausgabe und verschickt die HTTP-Header des Dokuments, bevor er die Ausgabe ausliefert.

Gehen wir zurück zur obigen AUssage zu Headern, werden die Header ziemlich genau in dem Moment „abgesendet“, in dem der PHP-Parser `echo` druchläuft.

{: #bedeutung}

Solange wir PHP in seiner Grundfunktion als Ausgabesprache nutzen, brauchen wir uns im Prinzip keine Sorgen um EVA und die HTTP-Header machen. Sobald wir etwas tiefer einsteigen, wird das schnell unabdingbar. Viele wichtige Mechanismen basieren auf dem Prinzip von HTTP-Headern:

All diese Funktionen müssen vor jeglichen Textausgaben des Dokuments geschehen, sonst resultieren sie in einem [headers-sent-Fehler]({{ page.root }}/jumpto/headers-already-sent/).

{: #umsetzung}

Der klassische Einsteigerfehler ist, die Anwendung nach dem Funktionsprinzip und nicht nach EVA zu gliedern:

Die Prüfung ist nicht direkt für die Ausgabe verantwortlich und kann deshalb früher erfolgen. Die Ausgabe ist sowieso nur für den Fehlerfall relevant, im Erfolgsfall wird ja gleich weitergeleitet.

{: #funktionsrueckgabe}

Die meisten der obigen Aussagen, lassen sich auf Funktionen übertragen. Meist dienen Funktionen ja dazu, wiederverwendbare oder zusammengehörige Funktionalität zu kapseln. Damit können Sie ein Paradebesipiel für EVA sein: Sie erhalten nötige Eingabewerte, stellen irgendetwas damit an und geben das fertige Produkt zurück. Leider sieht die Realität sehr oft immer noch so aus:

Die Funktion stellt sozusagen den Schritt „Verarbeitung“ dar, Ihre Schnittstellen die Schritte Eingabe (Liste der Parameter) und Ausgabe (Return-Wert).

{: #methodenrueckgabe}

Auch in der objektorientierten Programmierung (OOP) läßt sich vortefflich schludern. Für Eingaben, vor allem die Instanziierung von Objekten, spiegelt sich EVA im Pattern der sog. Dependency Injection wieder, wir wollen aber zunächst die Methodenrückgabe betrachten.

<div class="alert alert-info"><strong>Information!</strong> Die vorliegenden Codes sind Lehrbeispiele und der Übersichtlichkeit halber stark vereinfacht. Der Sinn, einen User ggf. ohne Altersangabe und ohne Validierung des Namens zu erstellen, ist natürlich in Frage zu stellen.</div>

{: #di}

Die obigen Codebeispiele zeigen auch einen einfachen Fall von DI. $_POST ist eine Superglobale und technisch gesehen ist es nicht notwendig, sie als Parameter von Methoden (Konstruktor und setAge ()) zu übergeben, sie ist ohnehin in jedem Kontext verfügbar. Schauen wir uns mal das obige Beispiel an, wenn wir diese Variablen einfach im Objekt auslesen:

Die Antwort auf alle drei Fragen lautet: Geht nicht, das Funktionsprinzip ist fest verdrahtet, dazu muß der Code für das Userobjekt geändert werden.

{: #includes}

...

{: #templating}

...

{: #mythos-if-schleife}

Zuerst sei ein oft vorkommender Mythos aufgeklärt:

`if` ist eine [Kontrollstruktur](http://php.net/manual/de/language.control-structures.php) aber deshalb noch lange keine Schleife.

{: #notierung}

Die korrekte Notierung gemäß [PEAR Standard](http://pear.php.net/manual/de/standards.control.php) beschreibt die Angabe immer mit geschweiften/geschwungenen Klammern `{ }`.

{: #uebliche-darstellung}

Nachfolgend eine übliche Darstellung, diese entspricht einem *entweder / oder*.

{: #verkuerzte-notierung}

Eine alternative, etwas kürzere Variante, mit Wert-Vorbelegung und Übersteuerung, wenn die Bedingung zutrifft.

{: #bedingungsoperator}

Der Bedingungsoperator `?:` (auch Konditionaloperator) gehört zur Gruppe der ternären Operatoren (Operatoren mit drei Operanden). Da diese Gruppe in vielen Programmiersprachen lediglich diesen einen Operator umfasst, wird `?:` oftmals einfach nach dem Namen der Gruppe als „ternärer Operator“ bezeichnet.

Bedingungsoperatoren finden häufig bei derartigen Zuweisungen Verwendung, weil auf diese Weise die Notwendigkeit wegfällt, die Variable vor einer `if`-Anweisung mit einem Standardwert belegen zu müssen, und weil gleichzeitig klar zu erkennen ist, dass die Variable unter allen Umständen mit einem Wert belegt wird.

{: #syntaktische-fallstricke}

{: #nur-ein-gleichheitszeichen}

~~~ php

Nur ein `=` Zeichen ist eine Zuweisung und würde immer als *true* gewertet. Zum direkten Vergleich sind zwei `==` oder drei `===` Zeichen nötig. Details dazu zum Thema *typschwacher* und *typsicherer* Vergleich gibt es [ebenfalls hier](http://php.net/manual/de/language.operators.comparison.php).

{: #ohne-klammern}

Ohne den geschweiften Klammern wird jeweils nur die erste Anweisung nach dem `if` ausgeführt. Nachfolgende Anweisungen werden, unabhängig davon, immer ausgeführt. Zur besseren Lesbarkeit wird grundsätzich von dieser Notaiton abgeraten, diese findet auch im [PEAR-Standard](http://pear.php.net/manual/en/standards.control.php) keine Anwendung.

{: #semikolon}

Ein Semikolon nach der Bedingung beendet für PHP die Anweisung sofort. Somit werden alle nachfolgende Anweisungen ausgeführt.

{: #unnoetige-konstrukte}

{: #pruefung-zu-bool}

Das Audruck in der Klammer `( )` nach dem `if` wird direkt immer zu *true* oder *false* ausgewertet. Mit diesem Hintergrundwissen fällt auf, das es oft unnötige Anwendungen des `if` Konstruktes gibt.

Weniger bekannt ist: PHP prüft den vor den einfachen (typschwachen) Vergleich beide Stringinhalte, ob diese einen numerischen Inhalt haben. Sind beide Stringinhalte numerisch, wird auch ein numerischer Vergleich durchgeführt. So auch wenn eine Seite ein numerischer Datentyp ist, was allgemein bekannt ist.

{: #beispiel-typschwach}

Diese Stolperfallen lauern versteckt auch in anderen Konstrukten, wie z.B. `switch` oder `usort`. Dazu die folgenden Beispiele.

{: #beispiel-switch}

{: #beispiel-usort}

Das Beispiel zeigt deutlich, dass `usort` bei Verwendung der Vergleichsfunktion `cmp` mit dem typschwachen Vergleich nicht das gewünschte Resultat bringt. `sort` und `usort` mit `cmpStr`, welche `strcmp` benutzt, arbeiten richtig.

{: #fazit}

Für den sicheren Stringvergleich auf Gleich/Ungleich kann nur der strenge Vergleich `===` bzw. `!==` empfohlen werden.

Wird in den obigen ersten Beispielcode konsequent `===` benutzt, bleibt die Ausgabe leer. Für einen größer/kleiner Vergleich von Strings bleibt nur `strcmp` zu nehmen.

{: #quelle}

* [Forumsbeitrag von jspit](http://www.php.de/php-einsteiger/95512-fallstricke-bei-typeschwachen-stringvergleichen.html)