Wiederkehrende Abläufe schreien nach einem Interface
Wenn immer dieselben abstrakten Abläufe gegeben sind, lohnt es sich über ein Interface nachzudenken
- Abstrakte Datentypen transformieren (cast)
- Aggregation, Delegation, Dependency Injection
- Asynchronous JavaScript and XML und Benutzerfreundlichkeit
- Ausführende Instanz für Remote Procedure Call ist die Framework-Instanz
- Byte-Semantic und Character-Semantic
- Chat mit WebSocket Broadcast und Client-Identifikation
- Class Loading via Perl Factory
- Code Vereinfachen in Methoden einer Factory
- Das Routing auf der letzten Meile übernimmt der Controller
- Data::Dumper wird nur geladen wenn er gebraucht wird
- Dateipfad von Modulen oder packages ermitteln
- Daten, Klassen, Eigenschaften und Methoden
- Design Pattern Factory Method
- Die an einen URL gebundene Subklasse definiert das Template
- DynDNS Client mit Perl Programmieren
- Ein anderer Aspekt der Factory
- Entity, Attribute, Value, abstrakte Datentypen und zyklische Strukturen
- HTTP Response Header werden gepuffert, der Puffer ist ein Attribut
- HTTP Response Status: 204 No Content
- INI-Dateien sind objektorientiert aufgebaut nach dem EAV-Muster
- Konfigurationen nicht als JSON sondern als abstrakte Datentypen
- Link, Rel, Canonical führen Duplicate Content zu einem gemeinsamen Ursprung
- MVC-Kompaktklassen im Perl-Framework
- Mehrfachverwendung an URLs gebundener Responseklassen
- Mein Web-Application-Framework als Interface in Perl implementiert
- Packages, Namespace, Scope oder Geltungsbereich von Symbolen
- Quasi Random Access File, Datei mit wahlfreiem Zugriff
- Templates in Methoden verwenden
- URL Routing mit dem Perl Framework über Subklassen
- Variablen oder Abstrakte Datentypen an eine Klasse binden
- Vererbung vermeidet redundanten Code
- Warum überhaupt eine Klasse für die Daten?
- Wiederkehrende Abläufe schreien nach einem Interface
Typischer Anwendungsfall: Ein Request kommt rein, die Response wird erstellt. So werden immer wieder dieselben Methoden aufgerufen. Es ist also naheliegend, diese Methoden als ein Interface aufzufassen.
header();
start_html();
menu();
bodybuild();
end_html();
All diese Methoden werden aufgerufen wenn der auzugebende Content-Type: text/html ist. Sofern ein davon abweichender Content-Type in der Response auszugeben ist, werden andere Methoden aufgerufen:
header();
content();
Das Umschalten zu anderen Interface-Methoden wird über ein Attribut geregelt. Im Grunde genommen ist das hier vorliegende Framework ein Interface, im Wesentlichen werden obenstehende Methoden aufgerufen. Wobei sich natürlich Verzweigungen ergeben, wenn Parameter im Request gesendet wurden.
Datenschutzerklärung: Diese Seite dient rein privaten Zwecken. Auf den für diese Domäne installierten Seiten werden grundsätzlich keine personenbezogenen Daten erhoben. Das Loggen der Zugriffe mit Ihrer Remote Adresse erfolgt beim Provider soweit das technisch erforderlich ist. sos@rolfrost.de.