Frage zu PHP 5 OOP

[MaxPayne]

Tag,

ich hab mir den (englisch-sprachigen) Teil der PHP 5-Doku zum neuen OO-Modell mal durchgelesen und war mal wieder erstaunt, was die Entwickler diesmal wieder geleistet haben. Echt Respekt.

Nun frage ich mich aber doch, wozu ich die Visibility-Optionen von Methoden eigentlich benutzen soll. Ich mein, wann ich welche zu benutzen habe ist klar. Aber warum sollte ich die eine Methode private und die andere public machen? Vor anderen Scripter schütze ich mich damit wohl kaum, wenn ich ihnen sowieso meinen Quellcode mitgeben muss - spart das irgendwie Ressourcen, wenn ich bestimmte Methoden als private oder protected deklariere und PHP somit keine Schnittstelle ans Objekt legen muss, damit die Methode von außen zugänglich bzw. vererbar ist?

Das hätte ich nun gerne mal gewusst.

Ich meine, wenn ich nicht will, dass diese oder jene Methode nicht vererbbar oder übers Objekt nachher verfügbar ist, dann spreche ich sie eben gar nicht erst an - warum sollte ich sie da extra "verstecken"?

[derHund]

damit klar definiert ist, wie der zugriff zu erfolgen hat?
damit interne änderungen nicht (zwangsweise) externe änderungen nötig machen?
um bestimmte methoden und daten vor externem zugriff zu schützen?
damit andere leute deinen code beerben können?
...

[TobiaZ]

ich hab mir den (englisch-sprachigen) Teil der PHP 5-Doku zum neuen OO-Modell mal durchgelesen und war mal wieder erstaunt, was die Entwickler diesmal wieder geleistet haben. Echt Respekt.

Wenn man bedenkt, dass es andere sprachen schön länger haben

angenommen es gibt methoden, die man nur innerhalb der class über $this->foo() aufrufen sollte. der aufruf von $object->foo() wird dann unterbunden.

Sicher, im groben und ganzen weiß man (da es bisher nicht anders ging) welche zu benutzen sind und welche nicht. aber so wirds nochmal unumgänglich verdeutlicht.

[MaxPayne]

@derHund

Warum? Wozu? Habe ich jetzt Angst vor mir selber, dass ich prophylaktischerweise alle Methoden die nicht vererbt oder übers Objekt aufgerufen werden als private bzw. protected deklarieren muss?

Ich kann doch genauso gut alle als public erstellen? Deswegen nutz ich die Funktionen von außen nachher genausowenig.

Und wenn andere mit extends meine Klassen vererben haben sie dazu sowieso den Code. Und wenn sie ne bestimmte Methode umschreiben wollen, die derzeit als private deklarier ist - was hindert sie daran in meinem Code das betreffende Wörtchen umzuänder?

Wuff.

[Big Chief]

Original geschrieben von MaxPayne
Warum? Wozu? Habe ich jetzt Angst vor mir selber, dass ich prophylaktischerweise alle Methoden die nicht vererbt oder übers Objekt aufgerufen werden als private bzw. protected deklarieren muss?

Hast du Angst davor deine eigenen Variablen nicht wiederzufinden, oder warum benennst du deine Variablen nicht einfach $a, $b, $c, $d,...?

Original geschrieben von MaxPayne
Ich kann doch genauso gut alle als public erstellen? Deswegen nutz ich die Funktionen von außen nachher genausowenig.

Ja .. du kannst sie auch $a, $b, $c nennen, und deswegen kannst du sie genausogut benutzen wie Variablen mit sprechenden Namen. Richtig.

Original geschrieben von MaxPayne
Und wenn andere mit extends meine Klassen vererben haben sie dazu sowieso den Code. Und wenn sie ne bestimmte Methode umschreiben wollen, die derzeit als private deklarier ist - was hindert sie daran in meinem Code das betreffende Wörtchen umzuänder?

Vielleicht wollen aber Leute, die deine Klasse benutzen, sich nicht erst du den ewiglangen Code deiner Klasse durchwühlen und die passenden Methoden suchen? Vielleicht wollen sie einfach nur wissen was sie reingeben müssen, damit das gewünschte rauskommt?
Oder stell dir mal vor, du hast komplexe Klassen mit 100 Methoden ... da haben die User bestimmt keine Lust den kompletten Quellcode anzuschauen. Aber ein User schaut mal kurz drüber, findet eine Methode die in seinen Augen scheinbar das richtige macht, und baut die gleich mal ein. Leider sollte diese Methode nur private sein, weil sie mit privaten Parametern rumspielt, die man von aussen gar nicht ändern soll ... und schwups wundert sich der Anwender, warum die Klasse nur noch Mist ausspuckt. Und wenn die Klasse groß genug ist, kann so eine Suche ziemlich lange dauern.

Natürlich hast du recht: man kann auch alles public machen .. aber wie mit den meisten anderen Dingen geht es hierbei um Anwenderfreundlichkeit, Wiederverwendung, Lesbarkeit, etc. ... wie den User mit 100 Klassen belasten, wenn er eigentlich eh nur 2 braucht und der Rest im Hintergrund arbeitet?

[MaxP0W3R]

Da sieht man, wer hier schon Objektorientiert gecoded hat und wer nicht ^^


Im "Klassenkopf" definiere ich quasi das Interface, alle Public Funktionen (optimalerweise keine Public Variablen, die sollten alle durch Public Funktionen gelesen und geschrieben werden)

OOP ist auch dazu da, im team zu arbeiten.

Leute, die ein Projekt zusammen bearbeiten, können auf den ersten Blick sehen, welche methoden für sie wichtig sind.

sagen wir ein Objekt auto

public gas_geben und public bremsen

rest ist geschützt.

jetzt weiss der Coder, der die Klasse einbindet, dass er sich nur um gas_geben und bremsen kümmern muss, was intern passiert hat ihn nicht zu interressieren.

ob jetzt bremsen intern abs() und esp() aufruft muss ihn nicht interessieren.

Würde er den ganzen Code lesen würde er vielleicht auf die Idee kommen, die 2 Methoden direkt aufzurufen, dabei gibt er aber esp vielleicht einen falschen parameter oder bemerkt einen seiteneffekt nicht, und schon funktioniert nichts mehr.

Der Coder der Klasse stellt der "Öffentlichkeit" die Methoden bereit, die sie braucht, was intern passiert ist geschützt. So kann der coder der klasse sicher sein, dass seine methoden nur so und so benutzt werden.

[derHund]

außerdem,

kann dann niemand dem $Auto->Speed einen unsinnigen wert zuweisen,

außerdem kannst du dann nur $Auto->startEngine(); aufrufen (wenn überhaupt), anstatt $Auto->Motor->Zylinder[3]->compress(8); was denn kolben zwar möglicherweise nach oben bewegt, die restlichen zylinder aber nicht ...

[MaxPayne]

@Big Chief:

Mal ganz davon abgesehen, dass deine ersten beiden Absätze NULL mit dem Thema zu tun haben - kann ich nichts mit anfangen. Was hat die Namensgebung mit der Visibility von Klassenobjekten zu tun?

Ob nun private oder protected - an der bequemen Scripterstellung und Nachvollziehbarkeit ändert sich nichts, bei sinngerechten Variablennamen schon.

Vielleicht wollen aber Leute, die deine Klasse benutzen, sich nicht erst du den ewiglangen Code deiner Klasse durchwühlen und die passenden Methoden suchen? Vielleicht wollen sie einfach nur wissen was sie reingeben müssen, damit das gewünschte rauskommt?

Und was hat das nun mit public oder protected zu tun? Auch NULL. Wie sie die Klassen benutzen, sage ich ihnen wenn dann mit einer Dokumentation.

Oder stell dir mal vor, du hast komplexe Klassen mit 100 Methoden ... da haben die User bestimmt keine Lust den kompletten Quellcode anzuschauen.

Davon, dass ich die eine Klasse als protected deklariere und die andere nicht, wird der Code nicht viel überschaubarer, oder? Um den Klassen-Code einzusehen muss er schon das Script öffnen, was auch nicht von Visibilitys-Optionen verhindert wird. Weißt du eigentlich wovon ich rede?

Aber ein User schaut mal kurz drüber, findet eine Methode die in seinen Augen scheinbar das richtige macht, und baut die gleich mal ein. Leider sollte diese Methode nur private sein, weil sie mit privaten Parametern rumspielt, die man von aussen gar nicht ändern soll.

Auch geben die Visibility-Optionen der Script-Datei keinen Schreibschutz.

aber wie mit den meisten anderen Dingen geht es hierbei um Anwenderfreundlichkeit, Wiederverwendung, Lesbarkeit, etc. ... wie den User mit 100 Klassen belasten, wenn er eigentlich eh nur 2 braucht und der Rest im Hintergrund arbeitet?

Ja, vor allen Dingen die Lesbarkeit ne, alles klar... Anwenderfreundlichkeit...auch klar, der Anwender wird in 90% aller Fälle die Klassenschnittstellen benutzen, die in der Doku stehen. Methoden, die man als protected deklarieren könnte um sie vor dem "versehentlichen" Gebrauch des anderen Coder zu schützen sind sowieso meist so aufgebaut, dass sie nur innerhalb der Klasse funktionieren und einzeln nichts Brauchbares zurückgeben.

Da sieht man, wer hier schon Objektorientiert gecoded hat und wer nicht ^^

Also Big Chief schonmal nicht. Wer mir schon erzählen will, dass die Lesbarkeit des Codes durch den Austausch des Wortes "private" durch "protected" verbessert wird ...

@Max

jetzt weiss der Coder, der die Klasse einbindet, dass er sich nur um gas_geben und bremsen kümmern muss, was intern passiert hat ihn nicht zu interressieren.

Das ist schon eher mal ein Ansatz. Aber das hätte er auch einfacher haben können, wenn er meine 3 Zeilen Dokumentation mal gelesen hätte.

Der Coder der Klasse stellt der "Öffentlichkeit" die Methoden bereit, die sie braucht, was intern passiert ist geschützt. So kann der coder der klasse sicher sein, dass seine methoden nur so und so benutzt werden.

Wie das geht hätte er auch aus einer Doku erfahren können. Der Script-Kunde muss die Datei mit der Klasse doch nur inkludieren und meine Doku lesen - mehr braucht er nicht.



Fazit:

Fakt ist, dass Visibility-Optionen in einer Script-Sprache - wo also nicht kompiliert wird - wo der Quelltext immer einsehbar ist bis auf den von Max genannten Beispiele nicht viel bringt. Es sei denn: PHP würde dadurch Perfomance-Sprünge machen, weil keine zusätzlichen Schnittstellen zu den jeweiligen Methoden und Eigenschaften gelegt werden müssen.


In der C-Familie hätte man eine Klasse als Shared-Object kompiliert - aus Lizenzgründen hätte man alle nicht-öffentlichen Klassen als private deklariert, damit der Anwender nichts über die Funktionsweise der Klasse erfahren kann - den Original C-Code hat er nicht, nur die kompilierte .so .

[MaxPayne]

Original geschrieben von derHund
außerdem,

kann dann niemand dem $Auto->Speed einen unsinnigen wert zuweisen,

außerdem kannst du dann nur $Auto->startEngine(); aufrufen (wenn überhaupt), anstatt $Auto->Motor->Zylinder[3]->compress(8); was denn kolben zwar möglicherweise nach oben bewegt, die restlichen zylinder aber nicht ...

Sicher. Aber im Endeffekt wird das Skript dadurch nur "idiotensicher".

[Big Chief]

Mit meinen ersten beiden Absätzen wollte ich nur Beispiele bringen, was man alles so machen kann, aber nicht muss (jedoch sollte).

und ausserdem .... ach, eigentlich ist das Wetter viel zu schön, als das sich jemand, der eh noch nie OO programmiert hat, weiter mit diesem Thema auseinandersetzen sollte .. in diesem Sinne ...

*schnappt sich ein Becks und knallt sich in die Sonne*

[derHund]

Sicher. Aber im Endeffekt wird das Skript dadurch nur "idiotensicher".

OffTopic:

---

du willst also sagen, daß du das prinzip der oop grundsätzlich ablehnst? naja, mir egal ...

---

[MaxPayne]

*lol* Sicher nicht. Im Gegenteil. PHPs OO-Modell ist zwar gegenüber anderen Sprachen (Ruby, Java) etwas gewöhnungsbedürftig, zeigt aber gerade durch seine Einfachheit seine Vorteile.

Ich wollte einfach nur den Sinn erfragen, warum man den C-ähnlichen Weg bei der Visibility gegangen ist.

[Abraxax]

Ich wollte einfach nur den Sinn erfragen, warum man den C-ähnlichen Weg bei der Visibility gegangen ist.

• weil sich C und PHP ähneln?
• weil PHP in C geschrieben wurde?
• weil es heute warm ist?

[TobiaZ]

OffTopic:

---

weil es heute warm ist?

Nee, das ist die Ursache für ganz andere dinge...

---

[MaxP0W3R]

OffTopic:

---

Ich vermute sowieso schon lange, dass der Streit (die Reibung) zwischen Anhängern der OOP und der Prozedualen Programmierung ein wesentlicher Faktor für die globale Erderwärmung ist...

---