nicht angemeldet
Objektorientierte Programmierung
Hallo,
suche Internetseite oder Buch zum Thema objektorientierte Programmierung, am besten mit Beispielen. Wie entwirft man eine Klasse? Was teilt man besser in mehrere Klassen auf? Welche öffentlichen Methoden sollte eine Klasse zur Verfügung stellen? Wie werden die einzelnen Funktionen nicht zu lang, aber wie braucht man umgekehrt nicht zu viele Methoden?
Wie initialisiert man ein Objekt? Mal wird es mit Daten aus einem Formular gefüllt, mal aus der Datenbank das nächste mal ist es vielleicht leer und stellt nur ein paar Methoden bereit?
Wie speichert man in PHP den Zustand eines Objekts? Speichert man das Objekt in einer Session Variable oder ist es besser es bei jedem Aufruf neu zu generieren?
Gibt es ein Buch zwischen "Einführung in PHP" und "Design Patterns"?
Gruß,
Christian
-
Tach!
Wie entwirft man eine Klasse? Was teilt man besser in mehrere Klassen auf?
Wie werden die einzelnen Funktionen nicht zu lang, aber wie braucht man umgekehrt nicht zu viele Methoden?Such mal nach dem SOLID-Prinzip. Gibts auch hier im Archiv (Autor: Sven Rautenberg).
Welche öffentlichen Methoden sollte eine Klasse zur Verfügung stellen?
Das kommt immer auf den Anwendungsfall an.
Wie initialisiert man ein Objekt? Mal wird es mit Daten aus einem Formular gefüllt, mal aus der Datenbank das nächste mal ist es vielleicht leer und stellt nur ein paar Methoden bereit?
Das kommt darauf an, was dessen Aufgabe ist. Ist es ein Datencontainer, dann im Konstruktor, oder unmittelbar nach der Instantiierung. Da bieten die Sprachen ja diverse Möglichkeiten. In C# beispielsweise muss man nicht unbedingt einen Konstruktor mit Parametern für alle Felder erstellen, man kann den Default-Konstruktor nehmen und die Felder mit dem Syntactic Sugar namens Object Intializer füllen.
Wie speichert man in PHP den Zustand eines Objekts? Speichert man das Objekt in einer Session Variable oder ist es besser es bei jedem Aufruf neu zu generieren?
Das muss man für den konkreten Anwendungsfall entscheiden.
dedlfix.
-
Hallo!
Geht es denn nur um PHP oder allgemein?
suche Internetseite oder Buch zum Thema objektorientierte Programmierung, am besten mit Beispielen.
Wenn es um PHP geht, ist das sicher kein schlechter Einstieg.
Wie entwirft man eine Klasse?
Indem man sich überlegt was die Klasse darstellen soll.
Tische haben oft 4 Beine, Tiere auch. Willst du jetzt eine Klasse darstellen die Elemente mit 4 Beinen darstellt oder doch eher jeweils eine für Tische und Tiere? Das kommt auf den Anwendungsfall an.Was teilt man besser in mehrere Klassen auf?
Willst du unterscheiden was alles 4 Beine haben kann oder willst du unterscheiden welche Tische oder Tiere 4 Beine haben können? Das kommt auf den Anwendungsfall an.
Welche öffentlichen Methoden sollte eine Klasse zur Verfügung stellen?
Das kommt darauf an was die Klasse darstellen soll. Jede Methode die in einer beliebigen Klasse öffentlich sinnvoll ist, kann in der nächsten Klasse obsolet sein.
Wie werden die einzelnen Funktionen nicht zu lang, aber wie braucht man umgekehrt nicht zu viele Methoden?
Folge der Direktive "don't repeat yourself!".
Wie initialisiert man ein Objekt?
Das kommt auf die Programmiersprache an und welche Methode(n) die Klasse zur Erzeugung eines Objekts benötigt.
Mal wird es mit Daten aus einem Formular gefüllt, mal aus der Datenbank das nächste mal ist es vielleicht leer und stellt nur ein paar Methoden bereit?
Genau.
Wie speichert man in PHP den Zustand eines Objekts?
Indem du die Eigenschaften eines Objektes, oder das Objekt selbst, in einer Form zurück gibst die du speichern kannst.
Speichert man das Objekt in einer Session Variable oder ist es besser es bei jedem Aufruf neu zu generieren?
Was genau meinst du mit "bei jedem Aufruf"? PHP speichert keine Objekte über mehrere Zugriffe. Wie du Objekte selbst speicherst, bleibt dir überlassen.
Gibt es ein Buch zwischen "Einführung in PHP" und "Design Patterns"?
Sicher. Aber was stört dich am Handbuch?
Grüße, Matze
-
Tach!
Welche öffentlichen Methoden sollte eine Klasse zur Verfügung stellen?
Das kommt darauf an was die Klasse darstellen soll. Jede Methode die in einer beliebigen Klasse öffentlich sinnvoll ist, kann in der nächsten Klasse obsolet sein.Einmal public lässt sich in einer erbenden Klasse dieses Mitglied nicht mehr verstecken, höchstens überschreiben. Wenn man so etwas (das Wiederverstecken) vorhat, dann hat man mit Sicherheit einen Fehler im Klassendesign.
Mal wird es mit Daten aus einem Formular gefüllt, mal aus der Datenbank das nächste mal ist es vielleicht leer und stellt nur ein paar Methoden bereit?
Genau.Dieselbe Klasse? Eigentlich gibt es grob gesagt zwei Sorten von Klassen, mehr oder weniger reine Datenspeicher und Klassen, die Handlungen vornehmen. Eine Kuh kann selbst zwar Gras fressen, aber melken macht jemand anders. Man müsste sonst die Kuh updaten, wenn man von Handmelken auf maschinelles umsteigen will. In Wirklichkeit muss man sich jedoch eine Melkmaschine anschaffen. Jedenfalls, wenn ein Objekt Daten aus einem Formular oder der Datenbank aufnehmen soll, sehe ich eine ziemlich geringe Wahrscheinlichkeit, dass diese Klasse Methoden hat, die auch ohne diese Daten sinnvoll arbeiten können. Das würde auch nicht mit dem SOLID-Prinzip konform gehen.
Gibt es ein Buch zwischen "Einführung in PHP" und "Design Patterns"?
Sicher. Aber was stört dich am Handbuch?Das PHP-Handbuch erklärt die OOP-Syntax aber kaum, wie man ein objektorientiertes Programm plant. Syntaxwissen allein macht noch keinen guten Prgrammierer aus. Sein Wunsch nach solchen methodischen Erläuterungen ist verständlich. Vermutlich wird ihm Literatur helfen, die sich mit objektorientierter Programmierung im Allgemeinen beschäftigt. Gab es da nicht mal ein Openbook von Galileo?
dedlfix.
-
Hallo dedlfix!
Einmal public lässt sich in einer erbenden Klasse dieses Mitglied nicht mehr verstecken, höchstens überschreiben. Wenn man so etwas (das Wiederverstecken) vorhat, dann hat man mit Sicherheit einen Fehler im Klassendesign.
Selbstverständlich. Ich bezog mich dabei auf völlig willkürliche Klassen ohne Vererbung oder anderes Gedöns. Ein gutes Beispiel wären setter und getter. Die eine Klasse wäre dadurch bereichert und bei einer anderen sind sie obsolet.
Dieselbe Klasse?
Nein. Ging es bei der Frage nur um eine einzelne Klasse? Dann ist das an mir vorbei gegangen. Sorry!
Sicher. Aber was stört dich am Handbuch?
Das PHP-Handbuch erklärt die OOP-Syntax aber kaum, wie man ein objektorientiertes Programm plant. Syntaxwissen allein macht noch keinen guten Prgrammierer aus. Sein Wunsch nach solchen methodischen Erläuterungen ist verständlich. Vermutlich wird ihm Literatur helfen, die sich mit objektorientierter Programmierung im Allgemeinen beschäftigt.Irgendwo habe ich den Faden verloren. Wo es am Anfang noch allgemein um Klassen ging, wurde daraus später PHP. Ich bin nicht sehr gut darin Probleme von Anfängern nachvollziehen zu können und fahre selbst mit dem Handbuch und den dortigen Kommentaren meist sehr gut.
Allgemein hast du natürlich mit allen Ausführungen recht obwohl wir an ein paar Punkten aneinander vorbei geredet haben.
Grüße, Matze
-
Tach!
Irgendwo habe ich den Faden verloren. Wo es am Anfang noch allgemein um Klassen ging, wurde daraus später PHP.
Naja, man kann OOP in der Praxis nicht wirklich losgelöst von der jeweiligen Programmierumgebung betrachten. Was in dem einen System nicht anders geht, oder aus anderen Gründen bestimmte Vorgehensweisen erzwingt, kann in einem anderen System mehr Nachteile haben oder kann ganz anders/einfacher gelöst werden. Getter und Setter sind in Java quasi Pflicht. Einige Systeme setzen darauf, bestimmte Namenskonventionen vorzufinden. (C# hat die Problematik mit etwas Syntactic Sugar viel besser gelöst.) In PHP hingegen sind viele Funktionsaufrufe, mitunter ein Performanceproblem, was man vermeiden kann, wenn es sich sowieso nur um 1:1-Durchreichungen an die internen Variablen handelt und keinerlei Zugrifflogik dabei irgendwas regelt. Zur Not kann man mit den Magic-Methoden __get/__set immer noch Getter/Setter gezielt für die das benötigenden Werte implementieren, ohne dass sich die API ändert. Kollektionen (als ein zweites Beispiel) bildet man ebenfalls nicht unbedingt in PHP nach, wenn man einfach die Universalstruktur PHP-Array verwenden kann.
dedlfix.
-
Hallo dedlfix!
Naja, man kann OOP in der Praxis nicht wirklich losgelöst von der jeweiligen Programmierumgebung betrachten.
Ja, deshalb auch eher der Hinweis auf das Handbuch (die einfache Suche nach "php oop tutorial" spuckt auch mehr als genug weiterführende Seiten aus).
Ich kann mich nur nicht ganz mit dem Satz
Vermutlich wird ihm Literatur helfen, die sich mit objektorientierter Programmierung im Allgemeinen beschäftigt.
nicht ganz anfreunden weil er meiner Meinung nach in gewisser Weise dem ersten Zitat widerspricht.
Grüße, Matze
-
Tach!
Ich kann mich nur nicht ganz mit dem Satz
Vermutlich wird ihm Literatur helfen, die sich mit objektorientierter Programmierung im Allgemeinen beschäftigt.
nicht ganz anfreunden weil er meiner Meinung nach in gewisser Weise dem ersten Zitat widerspricht.Das sieht so aus, ja. Das PHP-Handbuch beschreibt nicht allzu viel mehr als die Syntax der PHP-OOP-Features. Das reicht nicht, um die generelle Philosophie hinter der OOP und allgemeine Lösungsmuster kennenzulernen, oder auch wie man Klassen designt und was die SOLID-Prinzipien sagen. Man sollte beides kennen, das Allgemeine und das Spezielle unter PHP.
dedlfix.
-
-
Moin!
In PHP hingegen sind viele Funktionsaufrufe, mitunter ein Performanceproblem, was man vermeiden kann, wenn es sich sowieso nur um 1:1-Durchreichungen an die internen Variablen handelt und keinerlei Zugrifflogik dabei irgendwas regelt. Zur Not kann man mit den Magic-Methoden __get/__set immer noch Getter/Setter gezielt für die das benötigenden Werte implementieren, ohne dass sich die API ändert.
Die Sätze enthalten Dinge, die ich als falsch betrachte und deshalb kommentieren muß:
Erstens: Es ist egal, wie man es implementiert, dass es Getter und Setter gibt - WENN man sie nachträglich hinzufügt, ändert sich die API, und wenn man irgendeine Typprüfung in die Magic-Methoden einfügt, ändert sich die API auch.
Und zweitens sind die Aufrufe über die Magic-Methoden deutlich unperformanter, als wenn man konkrete Funktionen bzw. Eigenschaften implementiert hat. Du vergleichst beides zwar nicht, aber dein Eingehen auf Performance zu Beginn und die Verbindung "zur Not kann man Magic-Methoden" implizieren mit diesem Vorgehen keine Performance-Einbußen.
Kollektionen (als ein zweites Beispiel) bildet man ebenfalls nicht unbedingt in PHP nach, wenn man einfach die Universalstruktur PHP-Array verwenden kann.
Es gibt allerdings einige PHP-Datenstrukturobjekte, die manche Aufgabe besser lösen, als das klassische Array. Siehe SPL Datastructures
- Sven Rautenberg
-
Tach!
In PHP hingegen sind viele Funktionsaufrufe, mitunter ein Performanceproblem, was man vermeiden kann, wenn es sich sowieso nur um 1:1-Durchreichungen an die internen Variablen handelt und keinerlei Zugrifflogik dabei irgendwas regelt. Zur Not kann man mit den Magic-Methoden __get/__set immer noch Getter/Setter gezielt für die das benötigenden Werte implementieren, ohne dass sich die API ändert.
Die Sätze enthalten Dinge, die ich als falsch betrachte und deshalb kommentieren muß:
Erstens: Es ist egal, wie man es implementiert, dass es Getter und Setter gibt - WENN man sie nachträglich hinzufügt, ändert sich die API, und wenn man irgendeine Typprüfung in die Magic-Methoden einfügt, ändert sich die API auch.
Und zweitens sind die Aufrufe über die Magic-Methoden deutlich unperformanter, als wenn man konkrete Funktionen bzw. Eigenschaften implementiert hat. Du vergleichst beides zwar nicht, aber dein Eingehen auf Performance zu Beginn und die Verbindung "zur Not kann man Magic-Methoden" implizieren mit diesem Vorgehen keine Performance-Einbußen.
Als "zur Not" betrachte ich den Fall, dass man aus gewichten Gründen nicht von Eigenschaftenzugriff auf Zugriffsmethode wechseln kann, wenn nachträglich ein Bedarf für eine Zugriffslogik festgestellt wird. Dann wäre für diesen einen (oder anderen) Fall der Notnagel Magic-Get/Set eine Option. Ich sehe da grad nicht, wo du eine API-Änderung siehst. Vorher war es $foo->bar = 'qux'; und nachher ist es das immer noch. Die Performanceänderung sollte sich im Rahmen bewegen, ich plädiere ja nicht dafür, alles auf Magie umzuschreiben, sondern nur die "Notfälle". Und das sollte letztlich immer noch performanter sein, als alles mit unfunktionalen Gettern/Settern zuzupflastern. Außerdem bewegt sich der Unterschied im Bereich der Mikrooptimierung.
dedlfix.
-
-
-
-
-
-
Moin,
Hammer Buch kann ich dir nur Empfehlen. Damit hab ich die Objektorientierte Programmierung gelernt, naja damit und mit einem Projekt was auf OOP aufbaut. Schafft einen guten Spagat zwischen Unterhaltung und Fachwissen. Zusätzlich sind noch praktische Beispiel mit verschiedenen Programmiersprachen drin.
Gruß
empfehlenswerter
T-Rex-
-
Tach!
OOP - Buch
das sieht sehr gut aus. Ich habe es bestellt.Genau dieses Buch meinte ich, das gibts zum kostenlosen Lesen bei Galileo Openbook. Der Verlag wird sich aber freuen, wenn du es trotzdem käuflich erworben hast.
dedlfix.
-
Hi,
OOP - Buch
das sieht sehr gut aus. Ich habe es bestellt.Genau dieses Buch meinte ich, das gibts zum kostenlosen Lesen bei Galileo Openbook. Der Verlag wird sich aber freuen, wenn du es trotzdem käuflich erworben hast.
Das Buch sieht vielversprechend aus, da lohnt sich das Kaufen.
Gruß,
Christian
-
-
-
-
hi,
http://framework.zend.com/about/
"Zend Framework 2 is an open source framework for developing web applications and services using PHP 5.3+. Zend Framework 2 uses 100% object-oriented code and utilises most of the new features of PHP 5.3, namely namespaces, late static binding, lambda functions and closures."
Und dann scheint es bezüglich dessen auch weitere darauf aufbauende Quellen via Google-Suche (Zend Framework object oriented) zu geben, zB.:
http://www.killerphp.com/articles/introduction-zend-framework/
"The Zend Framework: Writing Object-Oriented PHP with Ease."
mfg
tami
-
Tach!
Meine persönliche Meinung ist, dass das Zend Framework (jedes andere Framework ähnlichen Umfangs ebenso) nicht wirklich geeignet ist, den Einstieg in die OOP zu finden. Man kann sehen, wie etwas ausgebaut ist, und dass viele Pattern Verwendung fanden. Aber dabei fehlt der pädagogische Ansatz, der das Lernen begleitet und das Wissen schrittweise aufbaut, bis man ein Level erreicht hat, ab dem man selbständig die Welt erkunden kann und zu verstehen in der Lage ist, warum ein bestimmtes Pattern an einer bestimmten Stelle eingesetzt wurde. Ein Anfänger ist sicher nicht einmal in der Lage, die verwendeten Pattern zu erkennen.
"Zend Framework 2 is an open source framework for developing web applications and services using PHP 5.3+. Zend Framework 2 uses 100% object-oriented code and utilises most of the new features of PHP 5.3, namely namespaces, late static binding, lambda functions and closures."
Wenn man sich aber das Get-Started-Tutorial durcharbeitet, bekommt man eher den Eindruck, es handle sich um eine array-orientierte Programmierung. Was da an Unmassen von ineinander verschachtelten Arrays anzulegen ist, nur um eine einfache Anwendung zu konfigurieren, geht auf keine Kuhhaut mehr drauf. Ich kann das Zend Framework nicht mehr guten Gewissens weiterempfehlen.
Das Problem an der Array-Konfiguration ist, dass die Keys alles Strings sind. "Stringly-typed" nennt man das auch. Bei Strings können einem die IDEs nicht wirklich sinnvoll mit Autovervollständigung helfen. Wenn das alles Klassen wären, wäre der Bauplan bekannt und die IDEs können einem direkt beim Tippen unter die Arme greifen. Aber mit Strings muss man sich immer merken oder nachschauen, welche es gibt und sie dann auch noch fehlerfrei abtippen (oder kopieren). Stringly-typed ist Mist!
Es gibt ja einige Alternativen, die sich in puncto OOP nicht zu verstecken brauchen. Das Yii-Framework ist sicher nicht zu Unrecht auf dem ersten Platz. Es machte auf mich auf den ersten Blick keine so schlechte Figur wie das ZF. Bereits beim Lesen des Tutorials hatte ich ein angenehmeres Bauchgefühl, auch wenn ich noch nicht die Gelegenheit hatte, ein Projekt damit aufzusetzen.
dedlfix.
-
hi,
Es gibt ja einige Alternativen, die sich in puncto OOP nicht zu verstecken brauchen. Das Yii-Framework ist sicher nicht zu Unrecht auf dem ersten Platz. Es machte auf mich auf den ersten Blick keine so schlechte Figur wie das ZF. Bereits beim Lesen des Tutorials hatte ich ein angenehmeres Bauchgefühl, auch wenn ich noch nicht die Gelegenheit hatte, ein Projekt damit aufzusetzen.
Ja, das ist aus meiner Sicht ziemlich Jacke wie Hose, welches OOP-Framework man sich mal zu Gemüte führt. Bei meinem letzten get-started mit Zend-Framework war alles ziemlich einfach.
Ich habe mich aber, als es noch keine 2....-Version gab, mal durch die Klassen gehangelt und dabei einiges gelernt, auf das man so ohne weiteres nicht kommt. Da hat sicher jeder seine eigene Herangehensweise. Immerhin haben die vom Zend-Framework sich ja vorher einige andere Frameworks zu Gemüte geführt (Ruby on Rails, Cake. Symfony etc.pp.) und sich dann aus allem was es bis dahin gab, das aus deren Auge sinnvollste zusammen gesucht. Aber sicherlich findest Du auch in anderen Framework "gutes" OOP.
mfg
tami
-
hi,
Es gibt ja einige Alternativen, die sich in puncto OOP nicht zu verstecken brauchen. Das Yii-Framework ist sicher nicht zu Unrecht auf dem ersten Platz. Es machte auf mich auf den ersten Blick keine so schlechte Figur wie das ZF. Bereits beim Lesen des Tutorials hatte ich ein angenehmeres Bauchgefühl, auch wenn ich noch nicht die Gelegenheit hatte, ein Projekt damit aufzusetzen.
S.a. http://blog.dirk-helbert.de/blog/2013/08/10/php-framework-vergleich-2013/
"Es ist natürlich immer schwierig eine Empfehlung für oder gegen ein PHP Framework abzugeben. Daher verlasse ich mich hier auf die Zahlen und würde bei einem neuen Projekt Symfony, Zend Framework oder Yii einsetzen."
mfg
tami
-
Aloha,
Immerhin haben die vom Zend-Framework sich ja vorher einige andere Frameworks zu Gemüte geführt (Ruby on Rails, Cake. Symfony etc.pp.) und sich dann aus allem was es bis dahin gab, das aus deren Auge sinnvollste zusammen gesucht.
Zend entstand 2005, genauso wie Ruby on Rails und Cake. Symfony entstand zwei Jahre später.
Ich weiß von Symfony, dass man sich da bei der Entwicklung ganz bewusst an Ruby On Rails orientiert hat (die Philiosophie ist deshalb bei vielen Dingen sehr ähnlich), Zend ist aber meines Wissens zumindest ursprünglich unabhängig entstanden. Allerdings hat man sicherlich auch da inzwischen viel von den anderen Frameworks angeschaut.
-
hi,
Aloha,
Zend entstand 2005, genauso wie Ruby on Rails und Cake. Symfony entstand zwei Jahre später.
Ich weiß von Symfony, dass man sich da bei der Entwicklung ganz bewusst an Ruby On Rails orientiert hat (die Philiosophie ist deshalb bei vielen Dingen sehr ähnlich), Zend ist aber meines Wissens zumindest ursprünglich unabhängig entstanden. Allerdings hat man sicherlich auch da inzwischen viel von den anderen Frameworks angeschaut.
Also ich habe mal ein Webinar mit den ursprünglichen Entwicklern gehört meine ich, dass sie die bis dahin bekannten Frameworks gesichtet hätten. Ich finde dies Quelle jetzt aber nicht auf die Schnelle. Wenn Symfony erst danach enstand, kann es das wohl nicht gewesen sein ;-). Vielleicht ja CakePHP?
In jedem Fall aber war es eine Antwort auf Ruby on Rails. Das habe ich ja schon verlinkt. Und findet sich auch hier: http://www.rau.ro/websites/e-society/lucrari/dragos pop 2.pdf
mfg
tami
-
-
-
hi,
Wenn man sich aber das Get-Started-Tutorial durcharbeitet, bekommt man eher den Eindruck, es handle sich um eine array-orientierte Programmierung. Was da an Unmassen von ineinander verschachtelten Arrays anzulegen ist, nur um eine einfache Anwendung zu konfigurieren, geht auf keine Kuhhaut mehr drauf. Ich kann das Zend Framework nicht mehr guten Gewissens weiterempfehlen.
Vielleicht ist das ja auch Geschmackssache. Ich finde die Best-Practices im Coding-Style überzeugend, ich weiß von Sven, dass er mittlerweile viel damit gearbeitet hat (oder musste/muss) und sehe, dass sich die Komplexität eben der Komplexität des Gebildes anpasst und auch der Aufgabenstellung. Verschachtelte Arrays, wenn sie denn sinnvoll aufgebaut sind, sind ein Abbild von Tabellenstrukturen im Grunde, nun ja, das brauchts dann halt irgendwie. So wie ich das verstehe, stellt das ZendFramwork eine Alternative zu Ruby-on-Rails "convention over configuration" dar. (S.a. http://devzone.zend.com/1420/zend-framework-18-preview-release/: "The argument is that ZF does not provide the “assumptions” or opinions on how an application should be built. However, this makes sense only if you buy into the idea that a framework should always follow the “convention over configuration” rule — which we soundly reject with Zend Framework. Our opinion has always been that developers know best how their application should be built, and that ZF code should support the myriad uses to which they will put it.")
Ansonsten finden sich in http://framework.zend.com/manual/2.2/en/user-guide/overview.html gleich am Anfang auch Klassen (Module), die erstellt werden müssen ...;
Dass das nichts für Anfänger oder nicht für jeden Anfänger was ist, mag ja sein. Das deswegen nicht zu empfehlen, kann ich nicht so wirklich nachvollziehen.
mfg
tami
-
hi,
Meine persönliche Meinung ist, dass das Zend Framework (jedes andere Framework ähnlichen Umfangs ebenso) nicht wirklich geeignet ist, den Einstieg in die OOP zu finden.
"While Zend Framework is the leading PHP application framework, there are also other great options such as Symfony, Laravel, Yii and many others. In fact, Zend Framework 2 was designed to provide modular building blocks that work efficiently along with other frameworks."
http://www.zend.com/en/solutions/framework-applications/
mfg
tami
-
-