nicht angemeldet
Tach!
Private Eigenschaften sind bei der Betrachtungsweise von außen ohne Belang,
Wer sagt das?
Das Black-Box-Prinzip.
Wenn die "privaten Eigenschaften" Einfluss auf das Verhalten ahben, sind die überhaupt nicth ohne Belang. Und wozu sollten sie sonst da sein, als Einfluss zu nehmen?
Für interne Speicherzwecke - ein Pointer eines Iterators zum Beispiel. Es interessiert mich als Verwender nicht, wie der Iterator sich merkt, welches Element als nächstes dran kommt, solange er mir das erwartete liefert.
Was von einer privaten Eigenschaft von außen sichtbar wird, wenn überhaupt, steht auf einem anderen Blatt. Falls der Wert allgemein interessant ist, wird es eine Zugriffsmethode geben. Und die kann auch noch je nach Implementierung Veränderungen vornehmen. Nur weil man mit PHP Einblick in den Quelltext der Klasse hat, heißt das noch lange nicht, dass man unbedingt deren Innenleben benötigt, um ihre Funktionsweise zu verstehen. Eine ausreichend ausführliche Dokumentation sollte genügen. Das funktioniert auch bei Dingen, die nur als Kompilat plus Dokumentation weitergegeben werden.
Wie gesagt, das ganze ist eine sehr theoretische Diskussion. In der Praxis wird man ohne Zweifel auf Sachen treffen, die von dieser idealisierten Vorstellung abweichen - warum auch immer - Fehler oder Absicht (oder beides gemixt).
Für die übrigen gilt das Gleiche!
Nö, öffentliche Eigenschaften sind deutlich stärker von Belang als private Dinge. Wenn öffentliche Eigenschaften sich undurchsichtigerweise verändern, ist das des Programmierers Schuld, nicht das der OOP.
Aber dein Argument ist nur ein scheinbares OOP-Argument. Man kann es auch auf die herkömmliche Programmierung anwenden. Funktionen können genauso undurchsichtig programmiert werden.
Was drehst Du mir das Wort im Mund um?
Vielleicht antworte ich einfach nur auf das, was ich verstanden habe und nicht was du sagen wolltest.
Bei der "herkömmlichen Programmierung" [...] muss man Variablen, die nicht geändert werden sollen, ja nicht in Funktionen "hineinstecken", von denen man das Verhalten nicht kennt.
Wenn sie von der Funktion nicht verwendet werden, interessieren sie auch nicht bei der Betrachtungsweise eines bestimmten Verhaltens. Ich glaube, ich verstehe grad nicht, worauf du hinauswillst.
Bei der OOP sollte man tunlicht keine Methode aufrufen, deren Wirkung man nicht kennt.
Und? Was ist dabei anders als bei der Nicht-OOP?
Bei der "herkömmlichen Programmierung" sieht man wenigstens noch in der Funktionsdeklaration, welche Argumente Referenzen sind, sich also veräbdern können.
Nur wenn sie keine Nebenwirkungen (neudeutsch side effects) hat. Funktionen tun auch interne Dinge mit lokalen Variablen, die natürlich irgendwelches Verhalten beeinflussen. Warum sollte das der OOP nicht im Rahmen ihrer erweiterten Möglichkeiten zugestanden werden?
Bei der OOP weiß man (ohne die _Implementation_ zu kennen), überhaupt nicht, welche Eigenschaften es gibt, wie die sich bei Methodenverwendung verhalten und verändern können und welche Wirkung das dann haben kann.
Genau wie bei der Nicht-OOP.
OOP ist mMn noch undurchsichtiger, als die "herkömmliche Programmierung".
Du hattest auch schon mal gehaltvollere Argumente. Zur Abwechslung kannst du ja mal über die Möglichkeiten der OOP nachdenken und nicht immer nur Nachteile in ihr suchen.
Wieso sollte man dann also keine Referenz-Argumente in einer Funktion verwenden?
Frage zurück: Warum sollte man, wenn es vielleicht besser geht? Wenn man mehr vom großen Ziel des OPs kennen würde, käme man vielleicht auf eine Lösung, die komplett anders funktioniert, sich damit besser in die Landschaft integriert und keine "ausgefallenen" Mittel verwenden muss.
Es ist ja auch kein Dogma, in PHP gibt es beispielswiese mit den Array-Sortierfunktionen Anwendungsfälle. Da ist der Anwendungsfall ziemlich klar: Das übergebene Array wird gemäß dem Funktionsnamen sortiert. Natürlich hätte man auch eine Funktion schreiben könenn, die ein sortiertes Array zurückgibt. Vermutlich hat sich jemand überlegt, dass man doch eher nur ein sortiertes und keine zwei Arrays braucht.
dedlfix.