Modulares Programmieren, Schwerpunkt PHP

Sir Robin

Erfahrenes Mitglied
Hallo,

ich wollte gerne etwas in PHP programmieren, und es dabei modular aufbauen. Dabei sollte es nicht so ablaufen, das etwa alle Config-Sachen in die config.php kommen, und alle Funktionen in die functions.php ... mein Verständnis von modular bedeutet für mich folgendes :

- es gibt ein Hauptprogramm
- es gibt viele kleine Module, die leicht in das Hauptprogramm integriert/installiert werden können OHNE am Code des Hauptprogramms was ändern zu müssen
- diese Module sollen auch wieder deinstalliert werden können

Okay, nehmen wir, damit wir in der hoffentlich folgenden Diskussion ein Beispielgegenstand haben, einfach mal das allgemeinläufige Beispiel CMS. Dieses CMS soll als optionale Module ein Gästebuch und ein Formmailer drin haben. Diese sind allerdings nicht standardmäßig mit im Funktionsumfang drin, und müssen deswegen als Module nachgeliefert und nachinstalliert werden.

Okay, mein Ansatz dazu sieht folgendermaßen aus:

Es gibt eine Hauptklasse names "modul", die von den jeweilgen Modulen erweitert (extended) wird. Diese Hauptklasse hat einige Funktion drin, die von allen Modulen gebraucht werden, als Beispiele hätte ich hier erstmal sowas simples wie "getVersion" oder sowas. Ansonsten wird sie jedoch nur als Basis genommen und wie schon erwähnt durch die Module erweitert.

Bisher sieht das also so aus:

PHP:
<?php

// Grundklasse
class module{
    //...
    function getVersion() {
        return $this->version;
    }
}

// Gästebuchmodul
class guestbook extends module {
    //...hier die Methoden für das Gästebuch
}

?>

...dann muss das Modul sich noch selbst aurufen, in Ermangelung einer Funktion wie main() ... (jaja...PHP :))

...meine Frage ist nun, ob ihr vielleicht in besseres Konzept, ein erweitertes Konzept habt, oder gar ein völlig anderen Ansatz zur Umsetzung der Modulidee habt. Ob sich dieser ganze OOP-Aufwand mit einer Sprache wie PHP 4 (anfangs 4, später wohl 5, je nach Release der Software und von PHP 5) lohnt? Das Problem daran ist, das es in PHP umgesetzt werden muss. Allerdings verstehe ich auch ein, zwei andere Sprachen, sodass ihr auch Beispiele in anderen Sprachen bringen könnt. Außerdem interessiert mich das Thema auch für die allgemeine Programmierung, ich habs halt nur aktuell in einem PHP Projekt ...

Danke schonmal
 
Ich würde evt. eine Klasse schreiben, die sämtliche Unterklassen verwaltet. Das würde das ganze etwas de-chaotisieren. Ausserdem würde ich die Unterklassen nicht die Vaterklasse extenden lassen, sondern sie einzeln behandeln und evt. Objekte übergeben (z.B. ein Datenbankzugriffsobjekt in den Gästebuchobjektkonstruktor :rolleyes:)
 
nightX, mein eigenes CMS basiert auf dem Prinzip.

Ich habe eine Art Container Klasse benutzt um die
anderen Klassen im Moment des Aufrufes (durch
den Template Parser) als Subklasse zu integrieren
und somit auf die wichtigen Funktionen der Container-
Klasse zugreifen zu können (Debugger, Datenbank)

Ausserdem benutze ich eine Art universelle Konfigurations-
datei, ähnlich der config. php bei PHPMyAdmin und der
Rest wird dann über die Datenbank gesteuert.

Wer Interesse hat an einem kleinen Plausch
über den Aufbau meines Systems, der melde sich
bitte bei mir. Kann in nächster Zeit zwar eng werden
zeitlich aber wird schon hinhauen.

Jona
 
Also der ansatz mit OOP ist sehr gut.. du solltest aber auf jedenfall aufpassen.. mit PHP5 und damit auch Zend2 werden ettliche neuerungen eingeführt,.... der Objective-core von Zend wurde komplett neu geschrieben.. mach dich also auf änderungen gefasst...

z.B. ist ein konstruktor neuerdings mit dem namen __construct zu definieren.. auch destruktoren gibts nun __destruct... und vieles mehr...
auch interfaces und class-type-hints stehen nun zur verfügung..

Nun aber ansonsten ist der ansatz gut..
 
Original geschrieben von chibisuke
Also der ansatz mit OOP ist sehr gut.. du solltest aber auf jedenfall aufpassen.. mit PHP5 und damit auch Zend2 werden ettliche neuerungen eingeführt,.... der Objective-core von Zend wurde komplett neu geschrieben.. mach dich also auf änderungen gefasst...

z.B. ist ein konstruktor neuerdings mit dem namen __construct zu definieren.. auch destruktoren gibts nun __destruct... und vieles mehr...
auch interfaces und class-type-hints stehen nun zur verfügung..

Nun aber ansonsten ist der ansatz gut..

Mmh, bis PHP5 aber standart ist, und *sämtliche* Server umgestellt sind dauert es aber noch...
 
Hallo,

danke erstmal für eure Antworten.

Der Ansatz mit der Oberklasse, die alle anderen Klassen verwaltet, gefällt mir an sich ganz gut. Mal gucken, wann Nils mal dazu kommt mir sein System zu erklären.

chibusuke:

Zum einen ändert PHP 5 nichts daran, das PHP immer noch keine OOP-Sprache ist, und zum Anderen seh ich derzeit bei dem Projekt noch wenig Verwendung von Interfaces etc. Was würdest du denn anders/besser machen, mit den neuen Möglichkeiten (mal abgesehen von den Zugriffsberechtigungen mit private,public etc.)

Johannes:

Das mit der PHP-Version ist nicht so das Thema, da das Projekt auf einem eigenen Server laufen wird. Aber da es sich hier ja um eine allgemeine Diskussion handelt, ist der Einwurf natürlich angebracht :)
 
nun prinziell würd ich es dann so machen:

ich würde die __access funktion nutzen um module die nicht geladen sind nachzuladen
dann würd ich eine zentrale hauptklasse machen, die zuerst einen URL parser lät, der feststellt welche site er denn nun azeigen soll...
dann erstellt der URL-Parser eine instanz der entsprechenden content klasse...

die klasse braucht zu diesem zeitpunkt nicht geladen sein, denn die __access methode sorgt dafür das diese nachgeladen wird automatisch...
eine entsprechende datenstruktur vorausgesetzt...leider wurde ein verfahren das in PHP4 funktioniert hatt (aber nie dokumentiert war) durch die erneuerung der Zend engine unbrauchbar...
man konnte den namen der klasse als variable direkt an den new operator übergeben.. steht zwar nicht in der doku, funktioniert aber in PHP4...in PHP5 geht das nicht mehr, entsprechend hier die verwendung des befehls eval()..

für session managment würde ich geziehlt den destruktor nutzen um die objekte die noch gebraucht werden zu serialisieren und in der datenbank zu speichern..
Datenbank-verbindungen könnte man geziehlt trennen, wenn das rendering abgeschlossen ist...

geltungsbereiche, natürlich..

die contents werden von einem interface abgeleitet, class-type-hints bzw. ein instanceof operator stellt sicher das es sich wirklich um eine contentclasse handelt... und noch vieles mehr...

basisklassen können nun endlich bestimmte funktionen als final definieren, damit diese nicht mehr überladen werden können... und noch einiges mehr...

PHP ist mit Zend2 nun doch noch zur OOP sprache geworden... meiner meinung nach, mehr als das was PHP kann vom OOP system her, kann man fast nicht erwarten..

klassen, interfaces, class-type-hints, construktor, destruktor, referenzierung, vererbung.. recht viel mehr kann man von einer objektorientierten programmiersprache nicht erwarten...
 
Ich habe vor einiger Zeit auch ein cms erstellt, wobei ich auch zig extensions hate.. die extensions waren so aufgebaut, dass sie im ornder extensions lagen.
Jedes extension hatte seinen eigenen unterordner wie z.B. GUESTBOOK, NEWS_SYSTEM usw. Jedes extension hatte den gleichen aufbau, im ordner befanden sich die dateien INDEX.PHP , SYSTEM.PHP , INSTALL.PHP und DEL_INSTALL.PHP.
Die index war dazu da, um in der Ausgabe eingebunden zu werden, mit den Funktionen, Klassen und all dem, was halt so benötigt wurde. bei der System.php gings halt darum, dass sie im admin bereich eingebunden wurde, und ich darin alles einstellen konnte, was ich halt so wollte. Sodele, die Install.php..
Eine Datei im admin bereich hat mir den ordner extensions durchsucht und alle unterordner mit dem namen angezeigt. Diese konnte ich also auch anklicken, und sofern die install.php vorhanden war, konnte ich den installieren button klicken.. dann wurden datenbank tabelle(n) und einträge erstellt und auf del_install.php weitergeleitet, wodurch die install.php gelöscht wurde. Sobald ich wieder auf den link des entsprechenden extensions klickte, wurde anstatt install.php (da nicht vorhanden) die system.php geöffnet .. wie gesagt, da konnte ich alle einstellungen vornehmen, unter anderem auch das extension einem menüpunkt zuweisen.

Joa das ganze fand ich damals ziemlich genial... Aber es war halt so gecodet, dass man mit ein wenig grundkentnissen und logischem denkvermögen das ganze noch ausweiten konnte...

gruss neuro
 
tja.. das is das ganze als prozeduzrales system.....

aber wiso sollte man prozedural programmieren wenn einem PHP schon die möglich zum OOP gibts?

`vergleich: wiso sollte jemand heutztage noch ein programm auf disketten kaufen, wenn jeder PC heutzutage n CD-ROM laufwerk hatt? Und CDs in der herstellung zdem noch günstiger sind als disketten...

nein wie gesagt.. im idealfall besteht jedes modus als einer datei... und jede content-seite aus einer datei.-..
die datei wird dynamisch von PHP geladen, ein objekt erstellt, und dann eben verarbeitet...
so kommt man auch mit methoden und variablen nicht durcheinander, weil eben alles in objekte gekapselt ist...
 
Zurück