Warum überhaupt eine Klasse für die Daten?
Ein etwas anderer Aspekt der Objektorientierten Programmierung.
- 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
Vererbung ist nur einer der Aspekte für eine objektorientierte Programmierung. Andere Aspekte sind wirtschaftlicher Natur und betreffen beispielsweise die Qualitätssicherung oder Kostensenkung.
Einen weiteren interessanten Aspekt soll dieser Artikel vorstellen: Eine Klasse definiert die Herkunft der Daten. Nun, was heißt das? Nehmen wir die Daten einer Browsersession, so wird sofort klar, dass diese Daten persistent gemacht werden müssen damit sie innerhalb einer Session erhalten bleiben, obwohl der Besucher die Seiten wechselt. Daten einer Session, was z.B. auch ein Warenkorb sein kann, liegen für den wahlfreien Zugriff in einer bstimmten Datenstruktur. Und jedesmal, wenn eine Response rausgegangen ist, werden diese Daten zurück auf die Festplatte geschrieben oder in eine Tabelle in MySQL.
In Perl sieht das z.B. dann so aus:
# Binde den Hash an eine Klasse
# Dateiname wird übergeben
tie my %session, 'SessionFile', file => 'sid.bin';
# füge ein paar Daten ein
$session{login} = {
group => 'admin',
user => 'Alfred',
};
# Änderungen persistent machen
tied(%session)->write;
Aufgrunddessen, dass die Instanz den Speicherort kennt, genügt der einfache Aufruf einer Methode.
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.