OOP: Kommunikation zwischen Objekten

Question

Hallo,

ich bin grad dabei, mich in OOP einzuarbeiten. Jetzt hab ich dieses Problem, wo ich nicht weiter weiß bzw. wo ich was nicht ganz verstehe:

Das Programm was mir vorliegt ist erstmal nur prozedural programmiert. Es besitzt eine Bootstrap-Datei, in die abhängig vom Url-Paramater "site" die zugehörige Datei inkludiert wird (es wird vorher auf gültige Seiten mit Hilfe eines Arrays geprüft), wobei jede Datei eben für eine bestimmte Seite mit einer bestimmten Funktionalität steht (z.b. Profil bearbeiten, irgendwas aus der DB lesen, irgendwas bearbeiten usw...).

Die erste Frage, die sich mir hier stellt: macht es Sinn, diesen Ablauf objektorientiert zu machen? Ich kann z.B. nicht den Sinn erkennen, wenn ich z.B. statt einer config-Datei mit Arrays einfach eine Klasse habe (statisch oder später als Objekt)...wo ist da der Vorteil? es ist ja beides zentral...und objekte verbrauchen doch mehr Speicher und mahct ein Programm prinzipiell langsamer? Kann man überhaupt komplett OOP programmieren (in Bezug auf die Bootstrap-Datei)?

Eine andere Frage die ich noch habe:
ich möchte eine Art MailQueue programmieren (ich weiß das gibt es schon bei Pearl, aber es geht ums prinzip). Wenn ich z.B. einen Cronjob hab, der mehrere mails verschicken soll, soll die Mailqueue diesen Cronjob entlasten, indem die zu verschickenden Mails in der DB zwischengespeichert werden. ich hab also eine Klasse für die Mailqueue, erstelle eine Instanz dafür und übergebe einige Parameter etc. Jetzt die Frage: Wie lasse ich das Objekt optimalerweise etwas in der DB speichern? Mir fallen da mehrere Möglichkeiten ein:
- ich übergebe dem Mailqueue-Objekt eine Referenz auf das DB-Objekt
- ich übergebe dem Mailqueue-Objekt die Zugangsdaten für die DB und lasse es alles selber machen
- ich lasse die DB-Geschichte komplett aus der Mailqueue raus und erhalte als Rückgabewert nur ein Array in einem bestimmten Aufbau oder z.B. einen SQL-String

Was ist das sinnvollste?

Vielleicht hab ich noch nicht alle Konzepte der OOP verstanden, aber es wäre schön, wenn ihr mir da auf die Sprünge helfen könntet...

Gruß Daniel

Answer 1

Der Sinn von OOP ist nicht, resourcen sparend zu programmieren, sondern komplexe Projekte für den Menschen übersichtlicher zu machen.
Meiner Ansicht nach macht Objektorientiertes programmieren erst bei größeren oder größer werdenden Projekten Sinn.
In der Praxis mache ich immer alles Objektorientiert, weil ich die Erfahrung gemacht habe, daß es immer komplexer wird, als vorher gedacht.
Wenn das Programm läuft und nicht verändert werden soll, lass es wie es ist. Wenn Du damit rechnest, daß es größer wird oder daß Du es später evtl. weiter verwenden und anpassen musst, macht es vielleicht Sinn, es in OOP umzusetzen.

Answer 2

OO kann schon sehr früh Sinn machen, dem sich viele aber gar nicht bewusst sind. Da eine neue Klasse von (einer) alte(n) erben kann vermeidet man so das schreiben von doppeltem (logischen) Code. Gibt es ein Problem, so kann man es an gezielt einer Stelle beseitigen und es wirkt sich auf alles erbende aus.

Genauso verhält es sich auch mit Erweiterungen oder gar erst der Problembestimmung - hier sind Klassen im Gegensatz zu traditionellem Code unheimlich einfach austauschbar. Beim Testen kann das schon hilfreich sein, um Problemherde einzugrenzen.

Außerdem kapseln Objekte Initialisierung und Deinitialisierung ihrer selbst - hier müssen also nicht gesondert Funktionen aufgerufen werden, um bestimmte Standardwerte zu setzen oder andere Dinge zu trennen, entsperren, sichern usw. Das ist bei steigender Komplexität der Projekte ein schnell einzusehender Vorteil. Selbst auf OO "konvertierte" Projekte sind so leicht zu bewerkstelligen, da man notfalls im Kon- / Destruktor etwaige vorhandene Funktionen aufrufen kann.

Konfigurationsdaten in einem Objekt sind natürlich Blödsinn, aber bitte nicht das drumherum vergessen: lese ich diese Konfigurationsdaten erst aus einer DB oder einer Datei können auf dem Weg dahin schon viele Fehlerszenarien entstehen, die alle behandelt werden wollen - hier kann eine Klasse schon schnell wieder idealer sein. Sind die Daten wirklich bloß ein starres Feld, dann kann man die auch getrost so lassen.

Zu deiner Mailqueue: übergib dem Objekt davon beim Erstellen (Konstruktor) das DB-Handle, welches es sich merkt. Oder übergib das erst in der dafür aufzurufenden Funktion. Damit vermeidest du eine zweite Verbindung zur DB, musst dir keine Gedanken über Verbindungsdaten machen, bleibst mit der Logik an Ort und Stelle, wenn das SQL-Kommando nicht erfolgreich abgesetzt werden konnte und kannst entsprechend reagieren.

Answer 3

Schonmal vielen Dank für die umfangreichen antworten.

Da das Projekt ziemlich schnell größer wird, auch jetzt schon, fange ich eben nebenbei an mit OOP.

Dann hab ich noch eine Frage zu Benutzern und OOP. Also mal konkreter:

ich habe ja wie gesagt die Bootstrap-Datei, in der neben der Login-Prüfung auch schon alle userdaten ausgelesen und in einem Array gespeichert werden, so habe ich mir einen SQL-Befehl gespart und hab alle userdaten sofort auf jeder Seite verfügbar. Macht das Sinn? Oder sollte ich lieber bei Bedarf konkrete Werte aus der DB nachladen?
Wegen der OOP: momentan ist es so, dass ich die Rechtevergabe über Felder in der Benutzertabelle handele. Da aber sehr oft neue Rechte hinzukommen, möchte ich das über eine gesonderte Tabelle machen mit einer Zuordnung. D.h. für jedes Recht, dass ein user besitzt, gibt es eben einen Eintrag in dieser Tabelle mit der user-id und der rechte-id. ich denke dass das so am sinnvollsten ist weil ich dann nicht mehr bei neuen Rechten in der Datenbank-struktur rumwurschteln muss.Jetzt die Frage: Wenn ich mir beispielsweise ein Userobjekt erstelle, sollte dieses (z.b. im Konstruktor) selbst die Daten aus der Datenbank lesen? oder sollte ich einfach die Struktur eines Users mit der Klasse vorgeben und die Werte über z.b. die Bootstrap-Datei füllen mit geeigneten Methoden? Das mit den Rechten würde ich innerhalb des Objektes einfach mit einem Array realisieren, d.h. für jedes recht gibt es einen Eintrag im Array, und dann kann ich mit isset() prüfen, ob das Recht vorliegt oder nicht...

Eine letzte Frage...welche Eigenschaften einer Klasse sollte ich Grundsätzlich Private, welche Public machen? ich würde es jetzt so machen, dass ich ALLE private mache, und dann entsprechende Getter und Setter-Methoden bereitstelle...macht das irgendwo keinen Sinn?

So viele fragen..ich hoffe ihr habt noch ein paar Tipps für mich :-)

Answer 4

1) Userdaten laden
Ich würd spontan sagen, erst bei Bedarf laden. Kommt aber auf verschiedenes an.
Vielleicht hast Du auch eine klasse 'userCollection' oder so?
Dort würde es vielleicht ein 'addUser()' geben, worin das Laden der Daten meiner Ansicht nach gut aufgehoben wäre.
Oder eben im User eine Methode 'getIrgendwelcheDaten()', die dann bei Bedarf über eine Datenbankverwaltungsklasse bequem auf die Datenbank zugreift.
Womöglich noch mit Umweg über eine Methode 'loadUserStuffFromDB()' in der userCollection, aber das ist wahrscheinlich noch nicht nötig.

2) Rechtevergabe
Wenns eine Obergrenze für die Anzahl der Rechte gibt, gehörts in die Usertabelle.
Wenn das Rechtemanagement komplizierter wird, müsste man über eine eigene Struktur fürs Rechtesystem nachdenken (Gruppen?)
Wenn wirklich weder die Anzahl der Rechte noch die Anzahl der user nach oben hin begrenzt ist, wird es früher oder später darauf hinauslaufen,
daß jeder User eine eigene Tabelle "Rechte", oder jedes Recht eine Tabelle "User" bekommt.
Was Du gerade machst, ist eigentlich genau das, nur daß alle User/Rechte Tabellen zu einer einzigen zusammengefasst sind. Kann in Ausnahmefällen Sinn machen (übersichtlicher sein). ZB: Datenmenge ist theoretisch unbegrenzt, praktisch aber ganz sicher nie 'zu groß', und die wartbarkeit und anpassbarkeit leidet nicht darunter.

Answer 5

Macht das Sinn? Oder sollte ich lieber bei Bedarf konkrete Werte aus der DB nachladen?

Auch hier musst du das selbst entscheiden: wie oft greifst du auf welche der Benutzerdaten zu? Entweder wird die Datenbank oder PHPs Speicherhunger während der Ausführung geschont...

Jetzt die Frage: Wenn ich mir beispielsweise ein Userobjekt erstelle,

Das ist dieselbe Frage von neulich. Wenn du mit meiner Antwort nicht weiterkommst, dann nimm darauf Bezug.

ich würde es jetzt so machen, dass ich ALLE private mache, und dann entsprechende Getter und Setter-Methoden bereitstelle...macht das irgendwo keinen Sinn?

Ausschließlich dann, wenn du sowohl beim setzen als auch beim auslesen der jeweiligen Eigenschaften nochmal dazwischenfunken willst (weil du z.B. weißt, dass es mehrere Leute gibt, die dann deine Klasse ebenfalls benutzen oder gar erben). Ansonsten ist das gänzlich unnötiger Code.