[php] Infos ueber Klassen

[Andreas Demmer]

Norbert Pfeiffer schrieb:

> Bei Scriptsprachen, wie PHP, ist OOP der absolute Performacekiller,
> weil erst mal alles in die 'traditionelle' Art umgesetzt werden muss,
> und das bei jedem Aufruf ... ;-)  
> 
> Das einzige, wo OOP wirklich eine 'Revolution' war, sind die
> Einnahmen der Softwarefirmen: viel Geld fuer neue Sprueche ueber alte
> Software. Aber auch Verlage und Schulungsfirmen haben voll
> 'abgesahnt'.   

Ich gebe Dir in sofern Recht, als dass vieles, was in OOP umgesetzt
wurde
nur um OOP zu sein, hätte auch einfacher mit prozeduralem Code erreicht
werden können. Doch spätestens bei der Wiederververwertbarkeit stösst
man
mit prozeduraler Programmierung schnell an die Grenzen.

Du magst es als "Copy & Paste" Programmierung bezeichnen, wenn man mit
Blackboxes arbeitet, von denen man nicht genau weiss, was sie denn
eigentlich
tun. Ich gestehe auch, zu der Fraktion zu ghören, die
selbstgeschriebenen
Code bevorzugen, wenn immer der Implementierungsaufwand sich in Grenzen
hält, aber warum sollte ich die 10.000. MIME Klasse schreiben, wenn ich
nur schnell aus meiner Anwendung heraus eine durchgestylte Email
verschicken
möchte? Die Anwendung mag die Killerapp sein, welche noch nie dagewesen
ist
und der Code mein genialer Einfall, aber muss ich deswegen auch ein Ass
in
der MIME-konformen Aufbereitung von Emails sein? Ein einfaches Beispiel:

$email = new email();
$email->setFormat('HTML');
$email->setFrom('ich at hier.de');
$email->setTo('do at dort.de');
$email->addAttachment('bild.jpg');
$email->addAttachment('info.pdf');
$email->setSubject('testmail');
$email->send();

Es kann mir egal sein, wie das Anfügen von Attachments funktioniert.
Und sollte die Klasse später neue "Tricks" lernen, etwa CCs, BCCs oder
Inline-Formate, so ändert sich an der bereits bestehenden API im
günstigsten
Fall erst einmal nichts, die neuen Befehle beinflussen die alten nicht:

$email->addCC('er at dort.de')
$email->addBCC('sie at dort.de');
$email->useInlineAttachments(TRUE);

Hätte man dies mit Funktionen gelöst, hätte sich der Funktionskopf
geändert und die Abwärtskompatibilität wäre zerstört.

Der zweite Vorteil von OOP ist, dass Objekte eigene Namespaces haben
und ihre Zustände aggregieren können. Will heissen: Selbst wenn jemand
anderes die Klasse geschrieben hat, überschreibt er nicht Deine
Variablen
selbst wenn seine gleich lauten. Und wann auch immer ich wieder das
Objekt
zugreife: Ich finde es so, wie ich es zuvor verlassen habe, mit allen
Attributen (Aggregation). Ich könnte es sogar dumpen und speichern.
Somit hätte ich beim nächsten Wiederherstellen alle Settings vom letzen
Gebrauch. Mach das mal mit Funktionen...

Gruss,
Andreas