Moin!

»» Nur mal so als herausgegriffenes Beispiel: Eine Klasse "Blog" - was tut die bei dir? Alles im Blog? Oder wieviele Unterklassen werden durch diese Klasse aufgerufen?

Wenn ich ehrlich bin - ja.
z.b. meine Newsletter Klasse, sie macht _alles_ sie erstellt die Tabellen in der Datenbank falls sie noch nicht vorhanden sind, sie hat sämtliche Funktionen wie. Newsletter als Entwurf speichern, ENtwurf ändern, Entwurf löschen, Entwurf verschicken, für den Newsletter eintragen, den Newsletter schreiben und direkt abschicken. Inklusive der Formular fürs "für den Newsletter eintragen", Etnwurfsänderung, Newsletter schreiben - das alles mit BB-Code-Unterstützung usw.. Sie hat 768 Zeilen ohne groß Abstände gemacht zu haben. Sie verarbeitet, holt, gibt aus und prüft. Ich dachte mir halt so wäre es das beste da ich wenn ich ein Projekt habe einfach nur die Datei inkluden muss und mir alles zur Verfügung steht.

Ja klar, dieser Gedankenansatz "ein Include, und ich habe alles, was ich brauche" ist natürlich naheliegend, wenn man kein Autoloading kennt und auch keine endlosen require_once-Arien in den jeweiligen Dateien ausführen will.

Aber allein bei deiner Beschreibung fallen mir schon mal folgende Ansatzpunkte für eigenständige Klassen ein:

1. Eine Datenbankklasse. Sowas schreibt man auch nicht selbst, sondern wählt vorhandene Frameworks. Als untersten Einstieg vielleicht PDO - das arbeitet noch sehr direkt mit SQL auf der Datenbank. Alternativ gern auch ein ORM-Framework wie Doctrine. Das übersetzt deine Datenbankinhalte gleich direkt in Objekte, die du neu erstellen, verändern, speichern, laden etc. kannst, und realisiert auch die Verteilung von 1:n und n:m-Relationen.

2. Eine Formularklasse: Generieren, Daten validieren, Fehlerbehandlung, Datenweitergabe in die Applikation. Wie ausführlich die nun sein darf, ist Ansichtssache, aber beispielsweise liefert Zend_Form einen brauchbaren Ansatzpunkt.

3. BBcode kriegt man auch in Klassen realisiert, ohne selbst Code schreiben zu müssen.

4. Nicht ganz klar ist die Frage nach einer Template-Klasse, aber auch die wird mit Sicherheit benötigt. Es muß nicht unbedingt Smarty sein, auch der MVC-Ansatz z.B. im Zend-Framework ist sehr brauchbar.

5. Eine Klasse zum Mailen. Wobei die wiederum zerfällt in eine Klasse, die gegenüber der Anwendung die Mails entgegennimmt, und einer Arbeiterklasse, die konkret basierend auf der Konfiguration des Mailservers die eigentliche Mail rausschickt.

Und so weiter, und so fort...

Tja, eigentlich sind ganz viele dieser Sachen absolute Standardaufgaben, die man ohne Probleme einem Framework auf's Auge drücken sollte, weil es im Ergebnis viel bessere Resultate gibt, wenn man seine eigene Energie auf die Lösung des primären Anliegens aufwendet, und alles, was nur am Rande mit dieser Aufgabe zu tun hat, aber dennoch erledigt werden muss, von einer Codebasis machen lässt, um die sich viele engagierte Entwickler kümmern, die viel wahrscheinlicher schon alle möglichen und unmöglichen Probleme dabei erlebt und gefixt haben.

»» Alternativ ist eine Klasse durchgehend statisch.

Das habe ich nur bei ein Datenbankklasse udn Utlilityklasse gemacht weil ich mir denke - die brauchste echt _überall_ die kannste auch statisch machen. Ist das nicht okay?
Alternativ gab sich mir auch noch das Singleton-Pattern aber ich fand die statische Methode sinnvoller.

Das Singleton-Pattern wird sowieso überbeansprucht. Ich persönlich mag es überhaupt nicht, weil man es sehr schlecht testen kann. Außerdem ist es zum Glück nur in wirklich wenigen Fällen tatsächlich angebracht - dummerweise wird es aber viel häufiger benutzt, vermutlich weil die Programmierer als einziges Pattern "Singleton" behalten haben und es deshalb immer und immer wieder umsetzen... :)

Ich habe mit Frameworks absolute Probleme. Von der Einstellung her.
Ich ich denke mir halt. Wenn ich mit Frameworks arbeite, geht mir der Lerneffekt absolut flöten.

Sehe ich anders. Frameworks helfen dir, dich auf die wirklich wichtigen Dinge konzentrieren zu können, nämlich das, was deine Webanwendung wirklich ausmacht. Klar, wenn du vorher noch nie eine Datenbankklasse geschrieben hast, fühlt es sich blöd an, gleich ein Framework zu verwenden. Andererseits: Wenn du einmal eine Datenbankklasse geschrieben hast, die noch nicht so wahnsinnig ausgereift ist, und du hast ein zweites Projekt - warum dann deine alte DB-Klasse verwenden, warum nicht ein gutes, funktionierendes Framework einsetzen?

Ich _hasse_ es, fremde Zeilen zu benutzen.

Dafür gibts sogar eine Bezeichnung: "NIH-Syndrom" - "Not invented here". Lieber das Rad ein zweites Mal erfinden, anstatt bestehenden, funktionierenden Code eines anderen Herstellers einzusetzen.

Diese Einstellung ist nicht nur jungen Einzelkämpfern zu eigen, sondern kommt in den besten Entwicklerkreisen vor.

Klingt jetzt wie ne halbe Lebengeschichte aber da ich auch keinen einzigen habe mit dem ich mich über das "hobby" unterhalten kann usw brauch ich halt "schnelle Erfolge" im Sinne von. Kleine Hürde setzen - bezwingen.

Kommunikation über Programmieren kriegst du hier im Forum mehr als genug, würde ich meinen. Sowohl als theoretische Diskussion über den allgemein richtigen Ansatz, als auch ganz konkret zu Code, den du postest.

Wenn ich mir jetzt ein Framework schnappe ist meine Motivation im Keller.

Warum dieses? Schließlich nutzt du ja schon ein "Framework", welches dich mit sehr vielen Funktionen versorgt: PHP. Was spricht dagegen, sich noch mit mehr Funktionen versorgen zu lassen, um etliche lästige Standardaufgaben zu eliminieren.

Auch mit Framework bleiben zahlreiche herausfordernde Programmieraufgaben zurück - nämlich alle diejenigen, die die Individualität der Software ausmachen.

Ich bin nicht mehr stolz darauf das ich dies und das geschafft habe - schließlich hat mir ja jemand anderes schon die Arbeit abgenommen und das Prinzip der ganzen Pattern und MVC usw ist mir dann immernoch nicht zu 100% nachvollziehbar.

Dass eine Menge zu Lernen ist, dagegen dürfte kein Kraut gewachsen sein.

Die Sache ist aber die: Wenn du schon so lange dabei bist, und jetzt auch vor OOP nicht zurückgeschreckt bist, nehme ich mal stark an, dass dir vorschwebt, das auch beruflich zu tun. Aber kein Kunde zahlt dir jedes Mal den Extra-Aufwand, für ihn ein individuelles Framework an Standardaufgabenlösungen zu implementieren - auch wenn du "dein" Framework dann jedesmal wieder zum Einsatz bringen könntest, irgendwelche Änderungen werden doch notwendig sein.

Und insbesondere wenn du mit Kollegen am Projekt zusammenarbeitest, bzw. der Kunde und/oder Chef befürchten muss, dass du als Kenner deines Frameworks nicht unendlich zur Verfügung stehen kannst, sondern irgendwann weg bist, wird die Abwägung zwischen einem speziellen Framework von dir oder einem globalen Open-Source-Framework mit zahlreichen aktiven Entwicklern sowieo weiteren zahlreichen Nutzern eindeutig in Richtung des bekannten, öffentlichen Frameworks ausgehen. Gehe also mal davon aus, dass du im Job zwangsläufig den Kontakt mit den wichtigen Frameworks haben wirst.

Vllt. sollte ich mich auch nicht schämen soviele Fragen zu stellen denn das hier bin auch ich. Ich wollte halt nicht 20 Fragen hintereinander stellen.

Tja, wenn du eine generelle Einschätzung zu deinem derzeitigen Projektcode haben willst, kommst du kaum umhin, nennenswerte Teile des Codes offenzulegen, um eine Inspektion zu ermöglichen.

Alternativ: Es gibt hier im Forum aktuell immer häufiger Diskussionen zu genau diesem Themenbereich: PHP OOP. Es ist nie falsch, die Diskussionen zu verfolgen und durch eigene Gedanken anzureichern. Es kann dir nichts besseres passieren, als wenn in so einer Diskussion deine Ansätze mit Begründung korrigiert werden. Das zweitbeste: Wenn sie sich als brauchbar erweisen. :)

- Sven Rautenberg