Wie geht man mit Klassen um

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Wie geht man mit Klassen um

    Guten (sehr früher) Morgen,

    ich bin ein fleißiger Programmierer in Sachen PHP und habe mich nun damit abgefunden, dass OOP der bessere Weg ist ein etwas größeres Projekt zu realisieren. Eine Klasse zu schreiben und daraus Objekte zu erstellen ist ja sehr einfach. Das kann ich auch soweit alles. Nun habe ich eine, für die meisten von euch wohl sehr, simple Frage.

    Ich weiß verdammt nochmal nicht wie man seine Klassen richtig aufbaut. Ab welchem Funktionsumfang es sich lohnt Klassen zu erstellen welche Methoden (Funktionen) die Klasse haben soll. Wie viel eine einzige Funktion machen sollte ( ob Sie nun etwas prüft UND in der Datenbank ändert oder ob es eine Funktion zum prüfen UND eine zum Ändern einiger Daten in einer Datenbank gibt ) und und und....

    Nochmal zusammen gefasst.

    • Wie baut man ein System mit verschiedenen Klassen auf ?

    • Ab wann lohnt es sich MEHRERE Klassen zu schreiben ?

    • Was sollte eine Methode (Function) machen oder darf/sollte eine Methode auch mehrere Dinge erledigen ?

    • Welche Objektvariablen lohnen sich wirklich ?

    • Muss ich die Objekte ganz am Anfang vom Script erzeugen und dann damit arbeiten, oder mittem im Script da die Objecte erzeugen wo sie gebraucht werden ?

    • Lohnt sich eine Klasse für Sessions, ein Login, eine Registration oder die Zuweisung der ID ?

    Das sind alles Fragen die ich mir immer wieder Stelle und ich selber noch nie eine Antwort gefunden habe. Manchmal stopfe ich wirklich ALLES in eine Klasse und manchmal erstelle ich für jeden, salopp gesagt, "Furz" eine Klasse.

    Ich bitte einfach nur darum eure Erfahrungen Preis zu geben. Wie arbeitet Ihr mit Klassen. Wie arbeiten die Klassen untereinander. Und und und.


    Ich hoffe ich werde in ein paar Stunden ein paar schöne Beiträge lesen die meinen PHP-Stil für immer prägen werden.

  • #2
    google: "PHP OOP Design Pattern, 2. Auflage"
    Wir werden alle sterben

    Kommentar


    • #3
      Willkommen im Forum.

      Ich würde empfehlen, dir ein größeres Projekt (Zend Framework oder Symfony etwa) anzusehen, um ein Gefühl dafür zu bekommen, wie Leute mit Klassen arbeiten, die relativ viel Zeit in ihr Design stecken. Da gibt es auch gute Dokumentation und sogar Bücher.

      Wie baut man ein System mit verschiedenen Klassen auf ?
      Das hängt von vielen Faktoren ab.

      - Model?view?controller - Wikipedia, the free encyclopedia
      - Hierarchical model?view?controller - Wikipedia, the free encyclopedia
      - Software design pattern - Wikipedia, the free encyclopedia

      - Dependency injection - Wikipedia, the free encyclopedia / Inversion of control - Wikipedia, the free encyclopedia
      - Law of Demeter - Wikipedia, the free encyclopedia

      - Professionelle Softwareentwicklung mit PHP 5

      - …

      Das musst du aber grundsätzlich nicht alles kennen, um OOP sinnvoll betreiben zu können. (Wobei, wenn ich die Liste der Muster so durchgucke… Doch, die meisten davon begegnen dir ständig – bewusst oder unbewusst.)

      „Inversion of Control“ (in dem Zusammenhang das Factory-Pattern) und „Law of Demeter“ sind meines Erachtens wichtig. Und das EVA-Prinzip und die Begriffe Model, View und Controller und Front-Controller (= alles läuft über eine index.php.). Das Konzept von „Global state“ und warum man es vermeiden sollte (= IoC/DI > Singleton/Registry), füge ich persönlich noch hinzu. Und eine steile These: Object composition/Interfaces > Vererbung.

      - EVA-Prinzip ? Wikipedia (Heißt in unserem Kontext im Grunde: Fang nich an, die Mitarbeiter-Liste an den Browser zu schicken, bevor du feststellst, dass die Firma „Existiert Nicht Productions“ und das Jahr 1251 nachgefragt sind. Das kriegst du mit MVC mitgeliefert.)

      Das klingt nach einer Menge Holz, aber Vieles davon ist erschreckend logisch. Dependency Injection bedeutet zum Beispiel im einfachsten Fall…

      PHP-Code:
      $logger = new Logger();
      $app = new Application($logger);

      $otherLogger = new OtherLogger();
      $app2 = new Application($otherLogger); // No problem here 
      …statt:

      PHP-Code:
      class Application {
          
      // ...
          
      public function __construct() { $this->logger = new Logger(); }
          
      // ...
      }

      $app = new Application(); 
      Application ist im zweiten Fall abhängig von einer konkreten Logger-Implementation, während im ersten Fall lediglich ein Logger übergeben werden muss, der die Vorgaben einer Schnittstelle erfüllt. Eine Instanz welcher konkreten Klasse das ist, ist aber nicht festgelegt.

      Faustregel dazu: Ein new-Schlüsselwort im Konstruktor ist falsch.

      Extremer: new gehört einzig in Factories. (Zieht kaum jemand durch.)

      PHP-Code:
      class ApplicationFactory {
          public function 
      createNewApplicationWithDefaultParts() {
              return new 
      Application(new Logger());
          }

      Ab wann lohnt es sich MEHRERE Klassen zu schreiben ?
      Einfache Antwort: Sozusagen immer. Aber ganz schwer zu erklären. Du kennst vielleicht ERMs aus der relationalen Datenbanktheorie. Was du da als Entity definierst, ist praktisch immer auch ein eigenständiges Objekt. Models/Services, die die Business-Logik implementieren, sind dann ebenfalls eigenständige Objekte, die mit diesen Entities arbeiten. Hinzu kommen dann Hilfs-Objekte wie der bereits erwähnte Logger oder ein Cache oder ein Filter oder ein Output-Renderer. Da würde ich mir wirklich mal ein Framework (siehe ganz zu Anfang) anschauen.

      Was sollte eine Methode (Function) machen oder darf/sollte eine Methode auch mehrere Dinge erledigen ?
      Hängt davon ab, was du modellierst. Richtlinien: Vermeide Redundanz, vermeide unnötige Komplexität (ein, zwei Bildschirmseiten sollten für die meisten Methoden ausreichen). So was organisiert sich oftmals selbst, weil Dinge umständlich werden, wenn sie falsch sind. Die Erfahrung wirst du selbst machen.

      Welche Objektvariablen lohnen sich wirklich ?
      Die Frage verstehe ich nicht.

      Muss ich die Objekte ganz am Anfang vom Script erzeugen und dann damit arbeiten, oder mittem im Script da die Objecte erzeugen wo sie gebraucht werden ?
      Die Frage beantwortet sich im Grunde dadurch, dass du zu Beginn des Scripts noch nicht unbedingt wissen kannst, was alles gebraucht werden wird. Auch im Zuge der Kapselung einzelner Anwendungsteile ist die Antwort: dort, wo sie gebraucht werden.

      Dass es Objekte gibt, die praktisch immer gebraucht werden (Logger, Nutzer-Objekt, Datenbank-Verbindung, …) und deshalb früh initialisiert werden müssen, dürfte auch nachvollziehbar sein.

      Lohnt sich eine Klasse für Sessions, ein Login, eine Registration oder die Zuweisung der ID ?
      Zend Framework oder Symfony (o. ä.) angucken. Die haben Antworten auf alle dieser Fragen.

      Was sich lohnt, ist oftmals fallabhängig. Du wirst vermutlich schon manchmal auf den Einsatz einer DB verzichtet und Daten in einfache CSV-Dateien oder so gespeichert haben. So ähnlich ist es auch mit so was.

      Ich nutze auch nicht gleich für alles das Zend Framework.

      Was in der Hinsicht vielleicht noch ein Tip wäre, der dich nicht gleich mit 8 Millionen Dingen zuschüttet:

      - Silex - The PHP micro-framework based on Symfony2 Components

      Das ist ein Mini-Framework, das einige „anerkannte“ Konzepte umsetzt, ohne die aber gleich in 1000 Klassen zu verpacken.



      So, das war jetzt die komprimierte Version von einigen Jahren Erkenntnisgewinn. Betrachte die Aussagen nicht alle als absolut. Viele der angeschnittenen Punkte lösen in einem Forum wie diesem sofort riesige Diskussionen aus, wenn man sie losgelöst diskutieren würde. Falls mich hier niemand korrigiert, liegt das einzig daran, dass niemand weiß, wo damit zu beginnen wäre.

      PS: Schau dir hinreichend zeitig PHPUnit an. http://www.phpunit.de/manual/current/en/index.html
      Zuletzt geändert von mermshaus; 16.04.2012, 07:11.

      Kommentar


      • #4
        Danke

        Vielen Dank für diese ausführliche und gut zu verstehende Antwort.

        Dann werde ich mir mal die Links alle nacheinander ansehen und mir mal so ein FrameWork ansehen.

        Auf bald.

        Kommentar

        Lädt...
        X