Wie geht man mit Klassen um

**combie** · 16.04.2012, 06:11

google: "PHP OOP Design Pattern, 2. Auflage"

**mermshaus** · 16.04.2012, 07:03

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

**vonHagen** · 16.04.2012, 18:27

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.

Wie geht man mit Klassen um