[Ben]

Hi,
ich habe nie darüber nachgedacht bis ich auf diesen Artikel hier gestoßen bin.
http://www.santosj.name/php/dont-advocate-subclasses/

Fazit: Subclasses oder "innere Klassen" werden nicht benötigt.

Ich habe mal anonyme innere Klassen in Java verwendet, aber das war ein komplett anderer Anwendungsbereich.
Der Autor sagt ja aus, dass innere Klassen in PHP nicht nötig und sogar "schlecht" sind.

Würde gerne ein paar Meinungen von unseren PHP-Theorie-Spezis hören.
Nicht, dass mir letztlich noch etwas "Tolles" entgeht oder so (auch wenn ich das eher nicht glaube). Man soll ja nicht alles so hinnehmen, was man so liest.

Grüße, Ben.

das ist geschmackssache und liegt in der entscheidungsgewalt des entwicklers. genau wie die sexuelle präferenz einem menschen freigestellt wird, ist es auch dem geschmack des entwicklers zu überlassen, ob er mit unterklassen arbeitet oder nicht. wozu gedanken daran verschwenden? die welt ist frei...

btw ist der artikel nicht gerade ernst zu nehmen ... man substituiert doch nicht nach belieben ein class mit einem array und sagt dann, dass die klasse nicht nötig ist. so ein schwachfug. desweiteren sind auch 'normale' klassen nicht nötig. ich kenne viele entwickler, die auch komplett ohne OOP zurecht kommen und funktionierenden code abliefern können. so what?

grüße
axo

[MrNiceGuy]

Also den Sinn einer solchen Anwendung habe ich a) noch nie gebraucht und b) noch nicht erkannt. Was soll es einem bitte bringen direkt in eine Klasse eine weitere einzufriemeln? Ich greife wenn dann überhaupt auf in der Klasse zur Laufzeit erstellte Instanzen anderer Klassen zu, ja, aber Klassen zu verschachteln, dazu fehlt mir die nötige abstrakte Sicht bzw. ein sinnvoller Anwendungsbereich!?

[Ben]

Zitat von MrNiceGuy

dazu fehlt mir die nötige abstrakte Sicht bzw. ein sinnvoller Anwendungsbereich!?

Ich kenn das.

@axo:
Jou, genau was du sagst .. der Artikel ist .. solala und deswegen habe ich hier mal nachgefragt.

Grüße, Ben.

dazu fehlt mir die nötige abstrakte Sicht bzw. ein sinnvoller Anwendungsbereich!?

gut fakturierter (bäh... aus diesem grund mag ich deutsch bei technischen diskussionen nicht) code besteht aus einer sehr großen menge an klassen, die jede für sich relativ klein sind (d.h. wenig code enthalten). high cohesion, low coupling.
allerdings verliert man leicht mal die übersicht (viele klassen-dateien, viele packages und subpackages), und es gibt extrem viele klassen, die eh nur in einem bestimmten kontext verwendbar sind. nichtsdestotrotz macht es oft sinn, diese winzigen objekte auch als objekte zu behalten und nicht aufzulösen. aber man kann sie erstmal aus dem "öffentlichen" namensraum befreien, indem man sie zur inneren klasse des klienten macht.

es ist daher hilfreich, eine weitere kapselungs-ebene einzuführen, um 1. die anzahl an files im projekt zu reduzieren und um 2. hilfsklassen auch als solche kenntlich zu machen.
nein, nötig ist es nicht. aber man kann die anzahl an nötigen packages und klassen reduzieren, und damit etwas mehr übersicht schaffen.
wie gesagt - religiös darüber zu werden macht keinen sinn. wer's mag, verwendet es, wer nicht, nicht. inner classes haben meiner meinung nach vorteile (kapselung, weniger files im projekt, evtl. bessere übersicht für den klienten, leichteres refactoring für den autor, und laufzeitunterschiede sind mir dabei reichlich egal), aber ich drehe keinem einen strick daraus, wenn er/sie inner classes nicht braucht.

grüße
axo

[Waq]

Das Problem bei PHP ist, dass es die Engine im Moment nicht schafft, irgend etwas anderes als einfache Variablen lokal zu halten, alles andere wird sofort globalisiert (Klassen, Funktionen...).
Und da selbst die Referenz-Magie der Variablen nur gerade so funktioniert, wäre es wohl wirklich ein Fehler, auf die schnelle lokal begrenzte Klassen einzuführen.

Die sollen irgendwann mal die Namespaces hinbekommen, lokale Klassen sind mir sowieso relativ egal, da wären mir closures in PHP wichtiger.

jo, das mit den referenzen ist so ziemlich das übelste an php. macht mich auch immer wieder wahnsinnig.
daher bleibt als quintessenz übrig: sollte ein php-projekt so groß werden, dass innere klassen vorteilhaft wären, sollte man aufhören, php zu benutzen.

grüße
axo

[Ben]

Zitat von axo

es gibt extrem viele klassen, die eh nur in einem bestimmten kontext verwendbar sind. nichtsdestotrotz macht es oft sinn, diese winzigen objekte auch als objekte zu behalten und nicht aufzulösen. aber man kann sie erstmal aus dem "öffentlichen" namensraum befreien, indem man sie zur inneren klasse des klienten macht.

Jou, das klingt ganz plausibel.

Allerdings nehme ich als persönliches Fazit diese Aussage hier

Zitat von axo

sollte ein php-projekt so groß werden, dass innere klassen vorteilhaft wären, sollte man aufhören, php zu benutzen.

[MrNiceGuy]

@axo: Danke für die Erklärung, es ist doch schon recht einleuchtend. Aber: Ich verstehe jetzt auch, warum ich diese Sichtweise nicht bedacht habe. Ich schreibe nämlich nicht für jeden kleinen Furz eine Klasse, da ich es unvorteilhaft finde, die OOP bis ins kleinste Byte zu vollziehen, denn weniger ist manchmal einfach mehr. Für diejenigen, die unbedingt eine Klasse schreiben wollen, die nur einen String enthält, bitteschön, für die macht es sicher Sinn, ich behalte dann doch lieber meinen etwas weniger OOP-lastigen Programmierstil bei und freue mich dennoch, dass ich bisher alles hinbekommen habe, was ich wollte