Leider gibt es in den PHP Tools für Eclipse einen kleinen Bug unter Windows wenn man ein eigenen Coding Standard verwenden will. Der PHP_CodeSniffer kann mit dem Parameter --standard aufgerufen werden und der CodeSniffer sucht in dem Pfad nach Sniff Dateien. Der CodeSniffer verwendet dafür die PHP Konstante DIRECTORY_SEPARATOR die ja bekanntlich unter Windows ein \ ist und kein /. Jetzt sollte man unter Windows den CodeSniffer wie folgt aufrufen:

phpcs --standard=C:\path\to\standard

Wenn man aber bei den PHP-Tools in die Debug Ausgabe schaut wird folgender Befehl ausgeführt

phpcs --standard=C:/path/to/standard

Dadurch findet der CodeSniffer die Dateien nicht.

Ich habe den Bug gemeldet und hoffe das es bald behoben ist.

Als Workaround habe ich den CodeSniffer innerhalb des PEAR Packet angepasst und folgende Zeile ergänzt:

PHP\CodeSniffer.php Zeile 400

$this->standardDir = str_replace('/',DIRECTORY_SEPARATOR,$this->standardDir);

In Eclipse muss man dann noch bei den PHP-Tools Einstellungen die lokale PEAR Libary verwenden.

Das PHP Pear Packet "PHP_Depend" eignet sich hervoragent zur Analyse der Code Qualität des eigenen PHP Projekts. Es lässt sich einfach über den Pear Installer installieren und kann dann auf der Comando Zeile über den Befehl "pdepend" aufrufen. Es wird nur PHP benötigt und kein Webserver oder Datenbank. Eine Installation unter Windows war ohne Probleme möglich.

Man kann PHP_Depend über einen beliebigen Code Ordner laufen lassen und sich dabei verschiedenen Formate ausgeben lassen.

JDepend ist ein Format aus der JavaWelt und wohl auch für den Namen des Projektes verantwortlich

JDepend traverses Java class file directories and generates design quality metrics for each Java package. JDepend allows you to automatically measure the quality of a design in terms of its extensibility, reusability, and maintainability to manage package dependencies effectively.

• --jdepend-chart=....svg Erzeugt eine SVG Grafik die die Instabilität in Abhängigkeit zur Abstraktion anzeigt
• -- jdepend-xml=...xml Gibt diese Informationen als XML Datei aus

Es gibt auch eine reine XML Ausgabe,  in der die Ergebnisse für jede einzelne Datei steht

• --summary-xml=....xml

Spannend ist auch die Pyramiden Darstellung

• --overview-pyramid=....xml

@package

Wenn man in seinen PHPDoc Kommentaren nicht mit dem @package Element gearbeitet hat muss man den Parameter --bad-documentation angeben. Lässt man den weg wird entweder gar nichts erzeugt oder nur für die Dateien die diesen Element besitzen. Um ordentlich mit dem Tool arbeiten zu können, sollte man @package ergänzen.

Typo3 Vergleich

Ich habe man den Kern von Typo3 Version 4 und 5 mit dem Tool analysiert:

JDepend Chart:

Typo3 4

Typo3 5

Überblick:

Typo3 4

Typo3 5

Aussagekräftig ist dieser Vergleich natürlich noch nicht, da Version 5 noch kaum Code enthält, aber man kann einen deutliche besseren Code erkennen.

Das Events Design Pattern ist ein sehr nützliches Pattern wenn man eine Anwendung hat in der sehr viel fachliche Logik auftritt und es ständig neue Anforderungen an bestehenden Prozessen gibt.

Beispielsweise kann es sein das nach einen Login verschiedene Dinge geprüft werden müssen. Zusätzlich sollen vielleicht noch Aktionen geloggt werden.

Wenn man jedesmal den Code für den Login erweitern würde, dann hätte man innerhalb kürzester Zeit eine riesige Klasse mit schwer wartbaren Code.

Bei dem Observer Pattern gibt eine Anwendung nur bekannt das ein bestimmtes Ereignis (Event) stattgefunden hat. Andere Programmteile können sich von außen an den EventDispatcher anmelden und werden dann von diesen benachrichtigt wenn das Ereignis eintritt.

In der PHP Bibliothek PEAR gibt es dieses Pattern schon fertig programmiert: Event_Dispatcher.

1. Handler erstellen

Als Erstes benötigt man einen Handler der das Ereignis verarbeitet.

class Handler{
/**
* @param    Event_Notification
*/
public function getOnlogin(Event_Notification $oEvent_Notification){
$oValueObjects_User = $oEvent_Notification->getNotificationObject();
$aInfos = $oEvent_Notification->getNotificationInfo();
// mach irgendetwas
}
}

2. Handler registrieren

Jetzt muss der Handler beim Event Dispatcher registriert werden.

require_once 'Event/Dispatcher.php';
$oEvent_Dispatcher = Event_Dispatcher::getInstance();
$oEvent_Dispatcher->addObserver(array(new Handler(),'onLogin'),'onLogin');

Der erste Parameter ist ein PHP Callback. Als dritten Parameter kann man von eingrenzen von welche Objekten dieser Event geworfen werden darf.

3. Ereignis auslösen

Jetzt muss das Ereignis noch ausgelöst werden.

require_once 'Event/Dispatcher.php';
Event_Dispatcher::getInstance()->post($this,'onLogin',$aInfo);

Im dritten Parameter kann man noch Informationen in Form eines Array übergeben.

Nutzen

Veränderung vermeiden

Der Nutzen in dem Pattern liegt darin das man die Anwendung nicht mehr nachträglich anpassen muss um Erweiterungen einzubauen.

Verantwortlichkeiten sauber trennen

Die Verantworltichkeit der Kompontenten bleibt frei von Nebensächlichkeiten. Zum Beispiel kümmert sich dann die Login Komponente nur um das Login und sonst nichts. Alles andere wird über die Events abgearbeitet.

Fazit

Ich verwende dieses Pattern sehr viel und es macht die Anwendung wartbarer und den Einbau von Erweiterungen einfacher. In anderen Sprachen wie .NET ist das Pattern bereits in die Sprache eingebaut.