heinetz: MVC | :: vs. ->

Hallo Forum,

ich versuche mir MVC zu erarbeiten und dabei OOP zu verstehen.

Ich habe mir diverse Beispiele angesehen, anhand derer das Prinzip MVC erklärt wird. Alle haben eines gemein:

  • In der Boostrap wird eine Instanz $controller = new Controller() gebildet;
  • In der Klasse Controller() wird mir this-> auf Methoden oder Eigenschaften der Instanz zugegriffen.
  • Im Controller steht wird eine Instanz $view = new View() gebildet;
  • In der Klasse View() wird mit this-> auf Methoden oder Eigenschaften der Instanz zugegriffen.

Beim Model wird anders verfahren. Hier und nur hier gibt es die Notation :: und in der Klasse wird gibt es sowohl folgende Notation this->Eigenschaft aber auch self::$Eigenschaft

Warum sieser Unterschied?

gruss,
heinetz

  1. Moin

    • In der Boostrap wird eine Instanz $controller = new Controller() gebildet;
    • In der Klasse Controller() wird mir this-> auf Methoden oder Eigenschaften der Instanz zugegriffen.

    nicht-statische Methoden dieser oder geerbter Klassen

    • Im Controller steht wird eine Instanz $view = new View() gebildet;
    • In der Klasse View() wird mit this-> auf Methoden oder Eigenschaften der Instanz zugegriffen.

    nicht statische Methoden dieser oder geerbter Klassen

    Beim Model wird anders verfahren. Hier und nur hier gibt es die Notation :: und in der Klasse wird gibt es sowohl folgende Notation this->Eigenschaft aber auch self::$Eigenschaft

    statische Methoden http://php.net/manual/de/language.oop5.static.php

    es gibt weitere Gültigkeits-Operatoren http://php.net/manual/de/language.oop5.paamayim-nekudotayim.php

    Gruß Bobby

    --
    -> Für jedes Problem gibt es eine Lösung, die einfach, sauber und falsch ist! <-
    ### Henry L. Mencken ###
    -> Nicht das Problem macht die Schwierigkeiten, sondern unsere Sichtweise! <-
    ### Viktor Frankl ###
    ie:{ br:> fl:{ va:} ls:< fo:) rl:( n4:( de:> ss:) ch:? js:( mo:} sh:) zu:)
  2. Tach!

    Beim Model wird anders verfahren. Hier und nur hier gibt es die Notation :: und in der Klasse wird gibt es sowohl folgende Notation this->Eigenschaft aber auch self::$Eigenschaft
    Warum sieser Unterschied?

    Was syntaktisch dahintersteckt hat Bobby ja schon gesagt. Warum man das an der Stelle so verwendet, kann man nicht erklären, ohne den konkreten Code gesehen zu haben. Man kann höchstens versuchen, allgemein zu erklären, warum man mal statisch und warum man mal über Instanzen an die Lösung der Aufgabenstellung geht.

    Bei einer Klasse, die mathematische Funktionen bündelt, braucht man im Normalfall keine Instanz. Die Methoden werden mit Parametern aufgerufen, berechnen daraus ein Ergebnis und das wars. math::sin(x) reicht als Aufruf. Berechnet, Ergebnis genommen, erledigt der Fall, eine Instanz ist überflüssig.

    class math {
      function sin(x) {
        return ergebnis_irgendwie_ermittelt;
      }

    function cos(x) {
        return ergebnis_irgendwie_ermittelt;
      }

    function tan(x) {
        return self::sin(x) / self::cos(x);
      }
    }

    Beim Berechnen des Tangens kann man die Funktionen für Sinus und Cosinus verwenden. Da aber keine Instanz existiert und auch nicht innerhalb der Tangens-Methode eine erzeugt werden muss, ruft man die beiden anderen Methoden statisch auf. Das self verweist dabei auf den Klassennamen. Stattdessen könnte man auch math::sin() und math::cos() innerhalb der tan()-Methode aufrufen. Man nimmt aber lieber den generischen Namen self, damit bei einem eventuellen Umbenennen der Klasse nur die eine Stelle anfassen muss und nicht noch viele andere geändert werden müssen (jedenfalls innerhalb des eigenen Codes der Klasse).

    dedlfix.

    1. Hakuna matata!

      Bei einer Klasse, die mathematische Funktionen bündelt, braucht man im Normalfall keine Instanz. Die Methoden werden mit Parametern aufgerufen, berechnen daraus ein Ergebnis und das wars. math::sin(x) reicht als Aufruf. Berechnet, Ergebnis genommen, erledigt der Fall, eine Instanz ist überflüssig.

      Um genau zu sein, ist in vielen Fällen nicht mal die Klasse notwendig oder sinnvoll, weshalb es auch völlig okay die Klasse wegzulassen.

      namespace Math;  
      function sin(x) {  
        return ergebnis_irgendwie_ermittelt;  
      }  
        
      function cos(x) {  
        return ergebnis_irgendwie_ermittelt;  
      }  
        
      function tan(x) {  
        return sin(x) / cos(x);  
      }
      

      Aber das ist ein anderes Thema.

      --
      “All right, then, I'll go to hell.” – Huck Finn
      1. Tach!

        Um genau zu sein, ist in vielen Fällen nicht mal die Klasse notwendig oder sinnvoll, weshalb es auch völlig okay die Klasse wegzulassen.
        namespace Math;

        Ja, Namespaces sind eine weitere Möglichkeit, Ordnung und Struktur in Code zu bringen. Das mag bei den Mathematikfunktionen auch recht sinnvoll sein. Sie sind alle im selben Themenbereich angesiedelt, haben aber weiter keine direkten Gemeinsamkeiten. Die Klasse, die hier nur statische Mitglieder enthält, ist nur ein Container, um diese irgendwie zusammenzufassen. Die Objektorientierung bleibt dabei auf der Strecke. Ob allerdings in dem von heinetz beobachteten MVC-Framework ebenfalls Namespaces ein sinnvoller Ersatz für die statischen Teile wären, muss erstmal offen bleiben.

        dedlfix.

    2. @@dedlfix:

      nuqneH

      Beim Berechnen des Tangens kann man die Funktionen für Sinus und Cosinus verwenden.

      Wird man aber nicht. Sinus berechnet man mit einer Reihe.* Cosinus berechnet man mit einer Reihe. Für Tangens müsste mann dann ja zwei Reihen berechnen; das will man nicht.

      Tangens berechnet man mit einer Reihe.

      „Wenn du schon mit Beispielen kommst, dann doch mit solchen, unter denen der Junge sich was vorstellen kann!“ (Otto) ;-)

      Qapla'

      * d.h. einer Summe von x (je nach Genauigkeit) zu berechnenden Gliedern, bspw. Taylor-Reihe (gibt aber sicher Reihen, die schneller konvergieren)

      --
      „Talente finden Lösungen, Genies entdecken Probleme.“ (Hans Krailsheimer)
  3. Moin!

    Hallo Forum,

    ich versuche mir MVC zu erarbeiten und dabei OOP zu verstehen.

    Zu MVC könnte ich direkt einen längeren Beitrag schreiben, der im Endeffekt dazu kommt, dass man im Webumfeld keinerlei MVC machen kann. Das Prinzip von MVC ist erfunden worden, um eine Lösung für ein Datensichtproblem zu bekommen: Wenn ich einunddieselben Daten an zwei oder mehr verschiedenen Stellen auf dem Bildschirm habe und an beiden Stellen bearbeiten können will, oder an einer Stelle bearbeiten und die Auswirkungen an allen anderen Stellen sehen will - dann ist MVC geeignet.

    Der View ist das Erscheinungsbild der Daten. Also beispielsweise ein Temperaturmesswert als Zahl, oder derselbe Wert als Punkt in einer Temperaturverlaufsgrafik.

    Das Model enthält die Daten selbst. Also die Speicherform, die geeignet ist, um die Daten irgendwo abzuspeichern und wieder einzulesen.

    Und der Controller ist zuständig für die Zusammenarbeit zwischen View und Model.

    Manipuliert der Benutzer in einer View einen Datensatz, meldet der View dies an den Controller. Dieser veranlasst im Model die damit einhergehende Operation. Und das Model informiert dann die View über die aktualisierten Daten - nicht der Controller! Vor allem aber: Model, View und Controller sind im originalen Konzept von MVC auf derselben Maschine - alleine damit geht MVC schon mal nicht im Web, denn wenn "die View" im Browser stattfindet, ist das garantiert eine andere Maschine, als die, wo Controller und Model liegen. Und deshalb kann das Model auch nicht die View über Datenupdates informieren.

    Das, was man im Web unter MVC großteils versteht, ist dies:
    View: Irgendwas mit Templates.
    Controller: Kommunikation mit dem Browser, Erkennen und Abarbeiten von User-Befehlen (-Klicks) und -Eingaben.
    Model: Verbindungsschicht zur Datenbank.

    Das hat mit objektorientierter Programmierung allerdings alles nicht zwingend zu tun. Im Gegenteil wirst du beim Versuch, OOP zu verstehen, durch Betrachtung von MVC vermutlich eher "versaut" - zumindest wenn du schlechte Tutorials liest, oder unkritisch Frameworks benutzt.

    Ich habe mir diverse Beispiele angesehen, anhand derer das Prinzip MVC erklärt wird. Alle haben eines gemein:

    • In der Boostrap wird eine Instanz $controller = new Controller() gebildet;
    • In der Klasse Controller() wird mir this-> auf Methoden oder Eigenschaften der Instanz zugegriffen.
    • Im Controller steht wird eine Instanz $view = new View() gebildet;
    • In der Klasse View() wird mit this-> auf Methoden oder Eigenschaften der Instanz zugegriffen.

    Beim Model wird anders verfahren. Hier und nur hier gibt es die Notation :: und in der Klasse wird gibt es sowohl folgende Notation this->Eigenschaft aber auch self::$Eigenschaft

    Warum sieser Unterschied?

    Weil das Tutorial blöd ist.

    Irgendwer hat sich dort gedacht: Hm, das mit dem Model muss rein, aber damit macht man ja meist Datenbankzugriff. Das wiederum ist zu kompliziert für das Beispiel, also: Daten fest im Model als PHP-Code ablegen. Aber man will ja nicht mit jeder Instanz eine neue Kopie der Daten haben. Also wurde anstatt einer Instanzvariablen eine statische Klassenvariable genommen.

    Das ist nichts anderes als eine globale Variable. Und damit absolut unschön! Vermeide sowas, wenn du OOP machen willst, denn OOP arbeitet - daher der Name - mit OBJEKTEN. Statische Variablen gehören aber zu keinem Objekt, also sind sie nicht objektorientiert. Sie gehören zu einer Klasse - sie sind allerhöchstens also klassenorientiert.

    - Sven Rautenberg

    1. Moin

      Das, was man im Web unter MVC großteils versteht, ist dies:
      View: Irgendwas mit Templates.
      Controller: Kommunikation mit dem Browser, Erkennen und Abarbeiten von User-Befehlen (-Klicks) und -Eingaben.
      Model: Verbindungsschicht zur Datenbank.

      Das nennt man MVP - Model View Presenter, wenn ich das hinzufügen darf. Der Controller als Presenter ist die zentrale Schnittstelle die das Model und den View steuert.

      Warum sieser Unterschied?

      Weil das Tutorial blöd ist

      Find ich nicht.

      Das ist nichts anderes als eine globale Variable. Und damit absolut unschön! Vermeide sowas, wenn du OOP machen willst, denn OOP arbeitet - daher der Name - mit OBJEKTEN. Statische Variablen gehören aber zu keinem Objekt, also sind sie nicht objektorientiert. Sie gehören zu einer Klasse - sie sind allerhöchstens also klassenorientiert.

      Du hast recht. es ist zu wenig hervorgehoben dass die statischen Daten nur exemplarisch sind und z.B. eine angehangene DB repräsentieren.

      Gruß Bobby

      --
      -> Für jedes Problem gibt es eine Lösung, die einfach, sauber und falsch ist! <-
      ### Henry L. Mencken ###
      -> Nicht das Problem macht die Schwierigkeiten, sondern unsere Sichtweise! <-
      ### Viktor Frankl ###
      ie:{ br:> fl:{ va:} ls:< fo:) rl:( n4:( de:> ss:) ch:? js:( mo:} sh:) zu:)
    2. Moin!

      ich versuche mir MVC zu erarbeiten und dabei OOP zu verstehen.

      Zu MVC könnte ich direkt einen längeren Beitrag schreiben, der im Endeffekt dazu kommt, dass man im Webumfeld keinerlei MVC machen kann.

      Das geht mir ganz ähnlich. Diesen ganzen Hype um MVC, Design Patterns und GoF sehe ich allenfalls als ein Henne-Ei-Problem und was Webanwendungen betrifft, da passt das Zustandsmodell (im Wiki unter EA, Endlicher Automat zu finden) viel besser, weil es praxisorientiert ist.

      Das hat mit objektorientierter Programmierung allerdings alles nicht zwingend zu tun. Im Gegenteil wirst du beim Versuch, OOP zu verstehen, durch Betrachtung von MVC vermutlich eher "versaut" - zumindest wenn du schlechte Tutorials liest, oder unkritisch Frameworks benutzt.

      OOP ist kein Selbstzweck, sondern eine praktische Angelegenheit. Ich kenne einige Programierer, die entwerfen die kühnsten Klassenhierarchien und wenn es um den Datenaustausch geht, wird dann mit allen Regeln der OOP gebrochen; beispielsweise werden dann ohne Not Instanzen von Klassen an Konstruktoren anderer Klassen übergeben.

      Und, um ein anderes Beispiel zu nennen, wozu in aller Welt sollte eine Class "Session" gut sein, wo es doch viel einfacher ist, in der Instanz, welche für das Ausliefern der Response zuständig ist, eine Referenz (Attribut) zu haben auf eine zweckmäßige Datenstruktur (Login-Tabelle, Warenkorb usw.). Denn nur dann kennt der Programmierer zuverlässig den Zeitpunkt, wann das Zurückschreiben der Daten spätestens fällig ist, nämlich in Destruktor seiner eigenen Instanz.

      Datenkapselung ist hierzu das Stichwort und eine Klasse allein bewegt noch gar nichts (danke für die Beispiele mit Sinus und Cosinüssen), genausowenig wie Vererbung immer sinnvoll ist. Vordergründig ist ein überschaubarer CODE der über Jahre verständlich bleibt, wachsen und gepflegt werden kann.

      Schöne Grüße.

      1. Hallo Hotti,

        Ich kenne einige Programierer, die entwerfen die kühnsten Klassenhierarchien und wenn es um den Datenaustausch geht, wird dann mit allen Regeln der OOP gebrochen; beispielsweise werden dann ohne Not Instanzen von Klassen an Konstruktoren anderer Klassen übergeben.link:

        Inwiefern stellt das für Dich einen Bruch mit OOP dar? Das, was Du beschreibst, ist das Prinzip der Dependency Injection (genauer Constructor Injection) und kann verwendet werden, die Abhängigkeiten von einer Klasse zu anderen Klassen zu reduzieren. Gerade für Unit-Tests ist sowas m.E. elementar wichtig, wenn man z.b. mit Mock-Objekten arbeiten will/muss - in solchen Fällen sind Klassen, die selbständig andere Klassen instanzieren, die Hölle (da nur schwierig einzeln, d.h. ohne die Infrastrukur der anderen Klassen, testbar). Ich habe  schon für Kunden gearbeitet, bei denen daher ein breiter Einsatz von Dependency Injection sogar eine Coding Guideline war.
        Ob das im Einzelfall sinnvoll ist, muss man natürlich abwägen, einen grundsätzlichen Bruch mit OOP kann ich da aber nicht erkennen.

        Und, um ein anderes Beispiel zu nennen, wozu in aller Welt sollte eine Class "Session" gut sein, wo es doch viel einfacher ist, in der Instanz, welche für das Ausliefern der Response zuständig ist, eine Referenz (Attribut) zu haben auf eine zweckmäßige Datenstruktur (Login-Tabelle, Warenkorb usw.).

        Was ist, wenn Du irgendwann man Sessions anders implementierst? Z.b. weil Du das DBS zur Verwaltung der Sessions wechselst? Oder weil Du Memcached-Server einsetzen möchtest, die bestimmte Informationen der Session zwischen-cachen, um sie schneller im Zugriff zu machen? Oder...
        -> Einfacher (und in vielen Fällen sicher auch völlig ausreichend) ist eine einfache Referenz auf das darunter liegende Objekt vielleicht, architektonisch kann es aber schon Sinn machen, die Applikationslogik von der Session-Verwaltung sauber zu trennen.

        Datenkapselung ist hierzu das Stichwort und eine Klasse allein bewegt noch gar nichts

        Doch, wenn sie sauber entworfen wurde, eledigt sie exakt eine einzige, wohl definierte Aufgabe.

        Vordergründig ist ein überschaubarer CODE der über Jahre verständlich bleibt, wachsen und gepflegt werden kann.

        Hierzu (und zu dem Rest Deines Posts) FULL ACK - Design Prinzipien sind, wie auch Programmiersprachen und Technologien, Werkzeuge, die man dann - und nur dann- nutzen kann und sollte, wenn es Sinn ergibt - nicht einfach nur, weil sie existieren :)

        Viele Grüße,
        Jörg

        1. Hallo Hotti,

          Ich kenne einige Programierer, die entwerfen die kühnsten Klassenhierarchien und wenn es um den Datenaustausch geht, wird dann mit allen Regeln der OOP gebrochen; beispielsweise werden dann ohne Not Instanzen von Klassen an Konstruktoren anderer Klassen übergeben.link:

          Inwiefern stellt das für Dich einen Bruch mit OOP dar? Das, was Du beschreibst, ist das Prinzip der Dependency Injection (genauer Constructor Injection) und kann verwendet werden, die Abhängigkeiten von einer Klasse zu anderen Klassen zu reduzieren.

          Klar. Nur halt andersherum, dann ist das OK: Nicht die Instanz übergeben, sondern in einer _eigenen_ Methode die Instanz einer anderen Klasse erstellen und erst dann die eigene Methode aufrufen.

          Gerade für Unit-Tests ist sowas m.E. elementar wichtig, wenn man z.b. mit Mock-Objekten arbeiten will/muss - in solchen Fällen sind Klassen, die selbständig andere Klassen instanzieren, die Hölle (da nur schwierig einzeln, d.h. ohne die Infrastrukur der anderen Klassen, testbar).

          Auch klar.  Meine Units kannste alle mocken, wenn fremde Klassen im Spiel sind oder deren Instanzen, lagere ich den Code aus in die Factory. Der Aufruf mit einer Attrappe (über eine Instanz oder den Namen einer Klasse) ist ja die Grundlage dafür, dass der Code wiederverwendbar ist, letztendlich ist er von der aufrufenden Instanz unabhängig.

          Ob das im Einzelfall sinnvoll ist, muss man natürlich abwägen, einen grundsätzlichen Bruch mit OOP kann ich da aber nicht erkennen.

          Streitfrage ;) Auf jeden Fall wird das Debugging erschwert wenn Instanzen einer Klasse als Argumente in Konstruktoren anderer Klasse übergeben werden. Per Factory wird das viel übersichtlicher, da sind auch fremde Klassen austauschbar, ein Griff in die Datei, fertig.

          Was ist, wenn Du irgendwann man Sessions anders implementierst? Z.b. weil Du das DBS zur Verwaltung der Sessions wechselst?

          Kein Problem, die Datenstruktur bleibt dieselbe. Stichwort Data Abstraktion Layer und der ist austauschbar.

          Oder weil Du Memcached-Server einsetzen möchtest, die bestimmte Informationen der Session zwischen-cachen, um sie schneller im Zugriff zu machen? Oder...

          Oh Vorsicht. In der Session liegen Userdaten und in dem Moment, wenn die Response raus ist, haben die im Hauptspeicher nichts mehr zu suchen. Dasselbe gilt für den Request, auch hier sind Userdaten enthalten. EINE Instanz, _ein_ Destruktor und _eine_ Stelle im Code, wo klar wird, dass es keine Referenzen mehr gibt auf Userdaten. Umso wichtiger, wenn der Prozess im Hauptspeicher verbleibt (FastCGI).

          -> Einfacher (und in vielen Fällen sicher auch völlig ausreichend) ist eine einfache Referenz auf das darunter liegende Objekt vielleicht, architektonisch kann es aber schon Sinn machen, die Applikationslogik von der Session-Verwaltung sauber zu trennen.

          Klar, wegen der Übersicht. EIN DESTROY und _das_ vererben wir gerne ;)

          Datenkapselung ist hierzu das Stichwort und eine Klasse allein bewegt noch gar nichts
          Doch, wenn sie sauber entworfen wurde, eledigt sie exakt eine einzige, wohl definierte Aufgabe.

          Methoden bewegen die Daten. Methoden im eigenen Namespace und weg mit globalen Variablen. Schlimm genug, dass es überhaupt welche gibt ;)

          Vordergründig ist ein überschaubarer CODE der über Jahre verständlich bleibt, wachsen und gepflegt werden kann.

          Hierzu (und zu dem Rest Deines Posts) FULL ACK - Design Prinzipien sind, wie auch Programmiersprachen und Technologien, Werkzeuge, die man dann - und nur dann- nutzen kann und sollte, wenn es Sinn ergibt - nicht einfach nur, weil sie existieren :)

          Herzlichen Dank für Dein Feedback,

          schöne Grüße.

      2. Hakuna matata!

        Das geht mir ganz ähnlich. Diesen ganzen Hype um MVC, Design Patterns und GoF sehe ich allenfalls als ein Henne-Ei-Problem und was Webanwendungen betrifft, da passt das Zustandsmodell (im Wiki unter EA, Endlicher Automat zu finden) viel besser, weil es praxisorientiert ist.

        Entweder ist unsere Wikisuche sehr schlecht, oder den Artikel gibt es nicht.

        Endliche Automaten sind in ihrer Rechenkraft sehr eingeschränkt, die Sprache über dem Alphabet {a,b}, definiert durch L ≔ {aⁿbⁿ | n ∊ ℕ} kann zum Beispiel beweisbar durch keinen endlichen Automaten entschieden werden.

        Wenn uns dieses eingeschränkte Rechnermodell reichen würde, dann würden wir unsere Webanwendungen wohl kaum in turingmächtigen Programmiersprachen entwickeln, sondern würden auf viel einfachere Sprachen zurückgreifen.

        Du kannst deshalb wohl kaum gemeint haben, dass man vollständige Webanwendungen als endliche Automaten modelliert, du beziehst dich bestimmt nur auf deinen Teil davon. So wie ich dich kenne, meinst du damit das Routing durch die Anwendung, die Parameterkontrollstruktur, wie du ihn immer nennst. In dem Bereich ist es nicht unüblich, dass man reguläre Ausdrücke benutzt (die ja genauso mächtig wie die endlichen Automaten sind). Deshalb kann ich mir vorstellen, dass man an dieser Stelle statt mit regulären Ausdrücken mit endlichen Automaten arbeitet. Mir ist allerdings kein Router bekannt, der wirklich so arbeitet.

        --
        “All right, then, I'll go to hell.” – Huck Finn
        1. Hakuna matata!

          Das geht mir ganz ähnlich. Diesen ganzen Hype um MVC, Design Patterns und GoF sehe ich allenfalls als ein Henne-Ei-Problem und was Webanwendungen betrifft, da passt das Zustandsmodell (im Wiki unter EA, Endlicher Automat zu finden) viel besser, weil es praxisorientiert ist.

          Entweder ist unsere Wikisuche sehr schlecht, oder den Artikel gibt es nicht.

          Über State und State Transition gab es in der Tat vor 15 Jahren mehr informative Artikel.

          Du kannst deshalb wohl kaum gemeint haben, dass man vollständige Webanwendungen als endliche Automaten modelliert, du beziehst dich bestimmt nur auf deinen Teil davon.

          Ich beziehe das Modell auf die einzelnen Zustände einer Webanwendung. Ein Zustand bestimmt z.b., wie die Daten dargestellt werden (Forum: Gesamtübersicht oder ein einzelner Thread oder ein Zustandsübergang beim Senden einer neuen Nachricht).

          So wie ich dich kenne, meinst du damit das Routing durch die Anwendung, die Parameterkontrollstruktur, wie du ihn immer nennst.

          Zum Teil. In meinem FW ist das Routing statisch aber die Zustände sind über Parameter abgebildet. Oder anders ausgedrückt: Das Routing hat einen statischen und einen dynamischen Anteil.

          In dem Bereich ist es nicht unüblich, dass man reguläre Ausdrücke benutzt

          Das Abbilden von Zuständen über eine Parameter-Kontrollstruktur hat mit regulären Ausdrücken gar nichts zu tun.

          Schöne Grüße.

          1. Hakuna matata!

            Du kannst deshalb wohl kaum gemeint haben, dass man vollständige Webanwendungen als endliche Automaten modelliert, du beziehst dich bestimmt nur auf deinen Teil davon.

            Ich beziehe das Modell auf die einzelnen Zustände einer Webanwendung. Ein Zustand bestimmt z.b., wie die Daten dargestellt werden (Forum: Gesamtübersicht oder ein einzelner Thread oder ein Zustandsübergang beim Senden einer neuen Nachricht).

            Programmzustände und Zustände von EAs sind mit Sicherheit vergleichbar, aber du kannst die Begriffe nicht einfach austauschbar gebrauchen. Ein endlicher Automat ist ein formales Modell, womit man reguläre Sprachen entscheiden kann. Eine Programmiersrpache ist in ihrer Berechnungskraft deutlich größer, nämlich in der Regel turingmächtig. Du kannst eine Programmiersprache deshalb nicht auf einen endlichen Automaten reduzieren, der umgekehrte Weg ist allerdings möglich.

            In dem Bereich ist es nicht unüblich, dass man reguläre Ausdrücke benutzt

            Das Abbilden von Zuständen über eine Parameter-Kontrollstruktur hat mit regulären Ausdrücken gar nichts zu tun.

            Ich sagte nur, dass es bei Routern häufig der Fall ist, dass man Routen ahand von regulären Ausdrücke spezifiziert. Beispiel dafür sind nginx, mod_rewrite, Symfony für PHP und express für Node.js.

            Dein Router arbeitet offenbar anders, nämlich mit der ominösen „Parameterkontrollstruktur“. Das ist dein gutes Recht. Ich habe nur spekuliert, wie man deiner Aussage, Webanwendungen würden besser auf das „endliche Automaten“-Modell passen, einen Sinn verleihen könnte. Da wir nun wissen, dass du irrtümlich einfach nur Programmzustände mit der Zustandsmenge von endlichen Automaten verwechselt hast, hat sich der Fall für mich erledigt.

            --
            “All right, then, I'll go to hell.” – Huck Finn