echo

Hallo Experten

Nachdem ich den scheinbar typischen Weg eines PHP-Einsteigers beschritten habe: Spaghetticode, ohne den Gebrauch von Funktionen ===> Etwas strukturierterer Code durch den Gebrauch von Funktionen, beschäftige ich mich jetzt mit OOP*.

Irgendwo, ich glaube es war sogar hier im Forum, habe ich gelesen, dass die größte Einstiegshürde beim PHP-Scripten mit OOP die ist, dass man erst mal das Prinzip einer objektorientierten Programmmierung kapieren muss, vor allem wenn man die ganze Zeit lieber Spaghetti in all seinen Variationen fabriziert hat. Wenn man das erst mal geschnallt hat und umdenkt, wäre alles ganz einfach.

Nun, so ganz habe ich das glaube ich noch nicht kapiert. Ich hatte mich mit der Theorie beschäftigt und wollte mir meine erste Klasse ausdenken:

Problem: Für meine Anwendung brauche ich immer wieder alle Inhalte einer MySQL-Tabelle namens "Kundentyp". Dort gibt es 2 Spalten ("id" und "Kundentyp"). Die Felder müssen in meinem Programm immer wieder in verschiedener Form angezeigt werden (mal innerhalb eines <select> - Feldes in einem Formular, mal nur als Liste, etc).

Also dachte ich, das könnte man durch eine Klasse lösen. Die Datenbankabfrage und die while-Schleife bleiben ja immer gleich:

Muss ich jetzt jede möglich Ausgabe (return) in einer Methode in der Klasse vordefinieren oder kann ich das (was meiner Meinung nach besser wäre) jeweils im Script nach Bedarf definieren? Wenn ja, wie? Oder habe ich OOP wirklich nich nicht ganz geschnallt?

Sorry, wenn dieser Beitrag etwas länger geworden ist und Danke an alle, die sich die Mühe machen, trotzdem zu antworten!

LG
l.

___
* Link-Tipp: Peter Kropff - Objektorientierte Programmierung mit PHP5 - Einführung

Mister Ad

Manko10

Dass dies Blödsinn ist, weißt du hoffentlich selbst:
Es gibt zwei Wege: entweder speicherst du alles in einem Array und gibst das zurück oder du gibst $ergebnis zurück und überlässt die Iteration dem Restcode. Beides hat seine Vor- und Nachteile.
Meinst lohnt es sich aber, für solche Fälle eigene Datenbankklassen anzulegen. Eine Klasse, die sich um den Verbindungsaufbau kümmert, einer Klasse, die den Query repräsentiert und eine Klasse, die das Ergebnis beinhaltet und von der Query-Klasse zurückgeliefert wird. Das ist aber schon etwas höhere Mathematik.

__________________
Refining Linux Advent Calendar series “24 Outstanding ZSH Gems”

tausche

Sodala, mein erster Vorschlag wär mal:

statt SELECT * FROM kundentyp würd ich SELECT id,kundentyp FROM kundentyp empfehlen, aber das nur mal so am Rande.

was spricht gegen return $ergebnis;

Ich tu mir noch ein bißchen schwer dein Problem nachzuvollziehen, willst du immer alle datensätze ausgeben? Dient das irgendeinem höheren Sinn oder soll einfach nur so ein Beispielcode sein?

Nachdems ja eher ums Verständnis der OOP Grundlagen geht, schrauben wir hier eigentlich doch am falschen Code, oder nicht?

mfg

Edit: bin scheinbar zu langsam für euch

echo

*hüstel* Sagen wir's mal so: Ich hab's schon staaaark geahnt. return bricht ja die Methode ab, gell? ...

Daran hab ich auch schon gedacht! Aber für den Fall brauch ich ja dann eigentlich keine Klasse, oder? Es sei denn ich hätte eine Klasse erstellt, die (wie von Dir angeregt) die Datenbankabfrage macht. Dann müsste ich, glaub ich meine neue Klasse kundentyp so machen:

Manko10

Und Madame hat eine Waschmaschine gewonnen.

Du kannst wunderbar prozedural programmieren. Es gibt Programmierer, die auf Funktionen schwören. OOP ist nur eine Alternative Herangehensweise. Es gibt keine bestimmten Situationen, in denen man unbedingt Klassen braucht und welche in denen das nicht so ist. OOP ist so konzipiert, dass die einzelnen Komponenten des Programms als reale Objekte aufgefasst werden. OOP ist praktisch die Nachbildung der Realität im Programmcode.

__________________
Refining Linux Advent Calendar series “24 Outstanding ZSH Gems”

echo

Keine Sorge, bin dankbar für jeden input!

Also, ich dachte mir so, dass ich irgendwie eine Klasse machen kann, die es mir ermöglicht, in der Klasse eine Methode zu machen, die mir bequem alle Felder der Datenbank ausgibt, die ich dann nach Belieben formatieren kann, z.B. so:Aber ich glaube echt, irgendwie schnall ich das mit OOP noch nicht. Kann es sein, dass OOP einen erst mal ganz schön zurückwirft und man plötzlich das Gefühl hat "Ich glaube, ich kann PHP doch nicht so gut, wich ich immer dachte" ? *seufz*

Screeze

Da bist du aber nicht die einzige, ich hab sogar ein buch darüber gelesen (mehrfach) und bin nicht soooo wirklich schlauer für was man das grundsätzlich benutzen sollte...

tausche

Also im Falle von PHP kann ichs nicht beurteilen, aber der Umstieg von prozeduraler auf objektorientierte Programmierung hat mich im Falle von C++ und Java doch an meinen Kenntnissen zweifeln lassen.

Aber es stimmt schon, wenn du mal das bisher gelernte Grundgerüst vergisst, ist OOP ganz leicht )

Also der Vorteil von OOP offenbart sich erst bei bestimmten Anwendungsbeispielen, wie von Manko bereits erwähnt, in deinem Fall ists mit sicherheit komplizierter und aufwendiger, das Ganze in OOP als prozedural zu realisieren, aber als Übung wirds schon hinhauen.

Im Allgemeinen solltest du ein Objekt haben, wie in deinem Fall das Objekt Kunde, der hat mehrere Attribute (id, kundentyp), und jedes Objekt vom Typ "Kunde" kann dann z.b. über die Methode Kunde.printout() die attribute aus der datenbank ausgeben.
Also liegt der Vorteil darin, dass du zig Objekte vom Typ Kunden haben kannst (eben den gesamten Kundenstamm) und für jeden Kunden (mit unterschiedlichen Werten in den Attributen) dieselben Methoden verwendest und das noch ausgesprochen bequem in einem Einzeiler - da machts dann meiner Meinung nach keinen Sinn die ganze Tabelle auszulesen sondern nur einzelne Datensätze - es sei denn ich versteh dich immer noch falsch.

Koala

ein Beispiel:

1. Du programmierst prozedural und mußt in Deinen
Projekten immer wieder die gleiche Blätterfunktion per
copy/paste ienfügen und die Breite des Ausgabebereichs, die sql-Abfrage etc.anpassen.

2. Du programmierst immer noch prozedural, aber strukturierst Deine Projekt übersichtlich (alle Anfragen über eine index, weitgehende Trennung von php unf html, include von header, content (je nach GET-(POST-Parameter)), footer).

3. Du machst eine Blätterfunktion welche HTML zurückgibt und übergibst ihr die Parameter (Ausgabebereichsbreite usw.).

4. Nun hast Du aber mehrere Funktionen und Eigenschaften welche sich auf das Blättern beziehn. Du faßt diese in einer Klasse zusammen.

5. Damit Du Programmlogik (PHP-Teil) und Ausgabelogik wieder schön getrennt hast unterteilst Du die Klasse in zwei Klassen:
eine zur Ausgabe(view) und eine mit den Berechnungen(controller).

Wenn Du Deine "Programmteile" alle entsprechend umgebaut hast
und dann noch eine Klasse hast welche die GET-/POST-Anfragen
an die jeweils zuständigen Klassen weiterreicht - dann hast Dein kleines privates OOP/MVC-Framework.

Screeze

hmm das is schon verständlicher als die ganzen auto varianten aus den meisten büchern...