2014-05-11T08:33:56 Muffi

Die Funktin würd ich einfach so schreiben.

Code (perl): (dl )

Scaliger::wochentag('4.10.1582')

Es bringt keinen Mehrwert hier OO zu verwenden.

Und mit dem "Es überschreibt sogar noch alles" meinte ich, dass das was das Objekt ausmacht ja wohl nur ein intern gespeichertes Datum ist und das
wird beim Methodenaufruf auch noch umgesetzt.
Ich find sowas nur verwirrend. Man fragt sich beim Aufruf, für was da ein Objekt gebaut werden muss, wenn eh nichts davon gebraucht wird.

Ja, ich verstehe schon was Du meinst, ist auch richtig und funktioniert. Bis auf den Mehrwert: Den gibts wirklich ;)

Ich hole mal ein bischen weiter aus mit einem anderen Beispiel:



Wegen einer sauberen Trennung der Fehlerbehandlung bez. Anwendungs- oder Eingabefehler wird der Konstruktor an dieser Stelle NICHT die userid validieren, so kann in $@ nur der Text für eine Exception stehen, die geworfen wird, wenn der Layer 'MySQL' nicht verfügbar ist (keine Verbingung zu MySQL).

So stehen in %user zunächst gar keine Daten und die Instanz $userobject hat nur das Attribut userid. Nun kommt der Getter ins Spiel und der hat den Namen FETCH.



FETCH wird nun aufgerufen aufgrund der Bindung tie(), FETCH wird mit dem privaten Attribut userid über den Layer nach den Daten greifen und jetzt kommt der springende Punkt, auf den ich hinauswill:

1) Es wird nur vname aus der DB gelesen,
2) Es werden alle Attribute des Users, vname, name, plz, ort, str usw. auf einmal geholt.

Klarer Fall, bei (1) wird jedesmal eine Abfrage nach MySQL gesendet. Auch wenn die Session bereits besteht und ein prepared Statement verwendet wird, kostet das Zeit.

Im Fall (2) erfolgt die Abfrage nur beim Erstenmal. Jedes weitere FETCH



kann auf Attribute zurückgreifen, die bereits in der Instanz vorliegen. Die Validierung, betreff einer sauberen Trennung der Fehlerbehandlung, erfolgt ebenfalls beim Aufruf des Getters FETCH: Wenn die userid nicht valide ist, kann es sich nur um einen Eingabefehler handeln (der Programmierer wendet die Klasse ansonsten richtig an).

Mehrwert also: Alle Daten, die organisatorisch zusammengehören, liegen als Attribute im Objekt, in der Instanz der Klasse und es kann performant darauf zzugegriffen werden.

Wenns ein bischen mehr Mehrwert sein darf ;)



Es wird keine neue Instanz erstellt, denn ein weiteres Attribut der bereits vorliegenden Instanz ist eine standhafte DB-Verbindung, die wir so nicht neu aufbauen müssen. Die Methode validate() wird userid an den Getter named FETCH durchreichen, fertig ;)

validate() ist ein Setter, alle Getter heißen FETCH. Ich denke, die Philosophie der Getter und Setter wird verständlicher, wenn Du mal eine eigene Tie-Klasse schreibst ;)

Tags: Performance, Code-Redundanzen, wiederverwertbarer Code, Datenabstraktion.
Last edited: 2014-05-11 14:34:46 +0200 (CEST)