[php] DB-Zugriff bei OO in php4

[Lutz Zetzsche]

Hi,

Am Samstag, 10. Dezember 2005 14:09 schrieb Lutz Zetzsche:
> Und gerade muß ich wieder an diese Diskussion denken: "Why getter and
> setter methods are evil"... Mal schnell gegoogelt - und hier ist ein
> Artikel dazu:
>
> 	http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
>
> Der Artikel stützt meine Eingangsaussagen und sagt noch viel mehr. Da
> finden sich so nette Sätze wie:
>
> "The most difficult problem in teaching object-oriented programming is
> getting the learner to give up the global knowledge of control that is
> possible with procedural programs, and rely on the local knowledge of
> objects to accomplish their tasks. Novice designs are littered with
> regressions to global thinking: gratuitous global variables, unnecessary
> pointers, and inappropriate reliance on the implementation of other
> objects."
>
> Oder:
>
> "Getter/setter methods often make their way in code because the coder was
> thinking procedurally."

ich habe gestern Abend aus Neugier noch ein Bißchen zu dem Thema 
weitergestöbert und bin auf einen Nachfolge-Artikel des Autors zu dem oben 
erwähnten Link gestoßen:

	http://www.javaworld.com/javaworld/jw-01-2004/jw-0102-toolbox.html

Interessant ist hierbei, wo man mit seinem Ansatz landet, get- und 
set-Methoden _komplett_ zu vermeiden... Konkret meine ich "Listing 4. 
Building an HTML representation" Seite 2 des Artikels. Hier ist allen Ernstes 
eine Builder-Klasse zum Objekt verantwortlich dafür, die Objektattribute für 
die Weboberfläche in HTML zu gießen...

Ich denke, daraus wird klar, daß man es auch nicht übertreiben sollte, denn 
sowas kann ja nicht die Lösung sein. :-) Auch Template Engines sind 
schließlich nicht umsonst erfunden worden. ;-) Und wer eine interaktive 
Benutzeroberfläche generisch an Daten- und Objektstrukturen orientiert, wird 
scheitern.

Was man aus der ganzen Geschichte mitnehmen kann, sind so Dinge wie: möglichst 
abstrakten / generischen Code schreiben, Klassen logisch in sich konsistent 
machen und unabhängig von Globalem halten, den Wirkungskreis einer Klasse auf 
das nötige Minimum beschränken, damit Änderungen nicht zu weite Kreise 
ziehen... Wenn ich aber am einen Ende eine Datenbank habe und am anderen eine 
interaktive Benutzeroberfläche, werde ich wohl irgendwo die Daten in ein 
Objekt setzen und wieder aus einem Objekt herausholen müssen. :-) Und wenn 
ich in der Datenbank einen Feldddatentyp ändere, dann schlägt es eben bis auf 
die Oberfläche durch - wie sollte es auch anders sein. ;-) Die interne 
Implementierung einer Klasse läßt sich halt nicht komplett verbergen, sonst 
kann ja niemand mehr etwas mit ihr anfangen. :-D

Trotzdem sollte man den übermäßigen Gebrauch von get und set vermeiden. :-) 
Warum sollte man z.B. für jedes Objektattribut eine eigene set-Methode 
(setAttributname()) haben, wenn es auch mit einer allgemeinen set-Methode 
geht, der man einen assoziativen Array übergibt. Das ist erstens schlankerer 
Code und vermutlich auch in der Verarbeitung schneller.


Viele Grüße
Lutz