Webentwicklung im Alltag

Auf phpperformance.de kann man eines von zwei Jahresabos für das PHP-Magazin gewinnen. Man muss nur einen Artikel mit Trackback auf die Seite veröffentlichen. Dann hoffe ich mal, dass ich einer der glücklichen Gewinner bin

Im Blog von Guido Mühlwitz habe ich heute über das neue interessante Workdpress Plugin AntispamBee gelesen und habe es auch sofort installiert. Damit hat Akismet nun wohl ausgedient.

Wieso das ganze? Google oder Facebook stehen in der Kritik, dass sie mit sensiblen Benutzerdaten nicht sorgsam umgehen und dass Daten deutscher Benutzer auf Servern in den USA gespeichert werden, was problematisch ist, da dort nicht mehr die Gesetzte des deutschen Datenschutzes gelten. Was jedoch kaum einer beachtet, ist dass auch das WordPress Plugin Akismet alle Kommentare nach Amerika schickt, um sie dort nach Spam zu durchsuchen. Was dann dort wirklich passiert kann keiner wirklich nachprüfen und auch wenn da nichts passiert so muss das doch nicht sein.

Was macht AntispamBee anders? Es gleicht die Kommentare mit dem öffentlichen Spammer-Datenbank Project Honey Pot ab. Ebenso kann man auch Kommentare aus bestimmten Ländern ganz sperren. Wer braucht zum Beispiel Kommentare aus Russland? Oder anders: Wie hoch ist die Wahrscheinlichkeit, dass ein Kommentar aus Russland in einem kleinen deutschen Blog wirklich ein echtes Kommentar ist? – Eben!

Also dann hoffe ich, dass auch viele andere Blogger dem Beispiel folgen und AntispamBee einsetzen. =)

Heute ist mein Artikel Inversion of Control auf PHP hates me erschienen. Danke nochmal an Nils, dass er mir diese Plattform geboten hat um meine Artikel auch einem größeren Publikum zugänglich zu machen. Ansonsten als Futter für die Suchmaschine hier nochmal der komplette Artikel.
—

Viele haben sicher schon einmal etwas von Inversion of Control (IoC) und
Dependency Injection (DI) gehört. Und sicher auch, dass es ganz toll ist
und es zu den best practices gehört. Nur eine Frage die oft nicht wirklich
beantwortet wird: Wieso ist das so sinnvoll?

Ich versuche hier einmal diese Frage mit einem Beispiel aus dem realen
Leben zu dokumentieren und zu beantworten…

Wir stellen und eine größere mittelständige Firma vor. Sie hat mehrere
Abteilungen die eigenständig arbeiten. Natürlich müssen da auch Dinge
angeschafft werden und das kostet Geld. Entsprechend ihrem Bedarf
bestellen diese Abteilungen also Dinge wie Drucker, Computer oder
Spezialhardware. Die Rechnungen werden in die Buchhaltung gegeben und dann
von dort aus bezahlt.

Das KANN alles super funktionieren. Aber nur dann, wenn diese Abteilungen
auch verantwortungsbewusst mit Geld umgehen und nur Dinge anschaffen, die
sie wirklich benötigen. Außerdem ist es schwer einen
Abteilungsübergreifenden Überblick zu bekommen, welche Hardware vorhanden
ist. Es kann auch passieren, dass mehrere Abteilungen die selbe
Spezialhardware bestellen obwohl sie sich diese eigentlich hätten teilen
können. Auch ist es schwer nachzuvollziehen wo denn das ganze Geld
geblieben ist.

Wie kann man diesen Zustand also optimieren? So wie es in der Praxis oft
gehandhabt wird: Die Abteilungen melden am Anfang eines Jahres ihren
Bedarf an, daraus wird ein Gesamtbedarf ermittelt und ein Jahresbudget
errechnet. Das wird dann angepasst und optimiert und jeder Abteilung ein
Budget, welches sie zur Verfügung haben, mitgeteilt. Größere Anschaffungen
müssen jedoch erst genehmigt werden (damit kann man doppelte Einkäufe
teurer Spezialhardware vermeiden). Und da diese größeren Anschaffungen nur
noch von einer zentralen Stelle vorgenommen werden hat man darüber auch
immer einen Überblick.

Und Dinge die sich so im Alltag bewährt haben machen auch beim
Softwaredesign Sinn. Wieso soll sich eine Klasse Gedanken machen woher sie
ihren Logger bekommt? Oder wo sie einen Zugang zur Datenbank findet? Das
ist gar nicht ihre Aufgabe. Es ist viel sinnvoller einer Klasse einfach
einen Logger oder eine Datenbankverbindung an die Hand zu geben und sie
macht das was sie am besten kann. Ihre eigene Logik zu implementieren.

Soweit die graue Theorie. Ich hoffe ich habe nun alle (oder zumindest
viele) von dem Nutzen der IOC und DI überzeugen können. Denn nun möchte
ich zeigen, wie die Umsetzung dessen in der Praxis aussehen kann.

Hier der bisher unschöne Weg wie eine Klasse Ressourcen verwendet:

class MyClass
{
 
    private $_logger;
    private $_dbHandle;
 
    function __constructor()
    {
        $this->_logger = Zend_Registry::get('LOGGER');
        $this->_dbHandle = Zend_Registry::get('DB');
    }
 
    function doSomething()
    {
        // etwas loggen
        $this->_logger->write('foo');
 
        // Daten aus der Datenbank lesen
        $this->_dbHandle->select('SELECT * FROM bar');
    }
}

Die Klasse holt sich im Konstruktor selber ihre Abhängigkeiten und
verwendet sie dann.

Besser ist folgender Ansatz:

class MyClass
{
    private $_logger;
    private $_dbHandle;
 
    function __constructor()
    {
    }
 
    function setLogger(Zend_Log_Writer_Abstract $logger)
    {
        $this->_logger = $logger;
    }
 
    function setDbHandle(Zend_Db_Adapter_Abstract $dbHandle)
    {
        $this->_dbHandle = $dbHandle;
    }
 
    function doSomething()
    {
        // etwas loggen
        $this->_logger->write('foo');
 
        // Daten aus der Datenbank lesen
        $this->_dbHandle->select('SELECT * FROM bar');
    }
 
}

Die Klasse bekommt ihre Abhängigkeiten über Setter-Funktionen gesetzt. Man
kann an dieser Stelle die Setter natürlich auch zugunsten von
Konstruktor-Parametern ersetzen. Ein offensichtlicher Vorteil ist schon
einmal, dass die Klasse sich nicht überlegen muss WOHER sie den Logger
oder das DB-Handle bekommt. Der Zugriff über eine Registry ist nichts
weiter als eine objektorientierte Form von globalen Variablen. Wenn sich
der Zugriffsbezeichner ändert, müssen alle Klassen angepasst werden. Ebenso
ist der Rückgabewert einer solchen Registry nicht Typsicher. Dieses Problem
haben wir über die Setter-Funktionen gelöst.

Soweit möchte ich hier erst einmal Schluss machen für diesen Artikel. Im
nächsten Artikel möchte ich dann einmal zeigen, wie man sehr einfach diese
Dependency Injection umsetzen kann.

Heute möchte ich einmal etwas über das Clean Code Developer (CCD) Projekt erzählen. Worum es dabei geht lässt sich schnell auf den Punkt bringen: besseren Code zu schreiben. Dafür wurden verschiedene Best-Practises gesammelt und strukturiert.

Grundlage bietet das Wertesystem des CCD. Dies besagt, dass guter Code folgende Eigenschaften erfüllt: Evolvierbarkeit, Korrektheit, Produktionseffizienz und Reflexion.
Evolvierbarkeit bedeutet, dass ein Code auch bei Änderung der Anforderungen anpassbar sein muss. Diese Flexibilität hat natürlich ihre Grenzen jedoch sollte man sie immer im Hinterkopf behalten. Korrektheit besagt, dass der Code eben das tun soll was er auch tun sollte. Produktionseffizienz beinhaltet wie lange die Entwicklung dauert und welche Ressourcen dabei verbraucht werden. Und Reflexion bedeutet, dass man sein Wissen und seine Erkenntnisse auch über den Code immer wieder überdenken und neu bewerten muss, da besonders auch in der Informatik sich viele Rahmenbedingungen ändern und auch immer neues Wissen geschaffen wird.

Um diese Ziele zu erreichen wurden verschiedene Prinzipien und Praktiken gesammelt und in sechs verschiedene Grade eingeteilt. Diese Grade kann man sich ähnlich wie die Grade beim Budosport vorstellen. Entsprechend dem Grad trägt man auch verschiedenfarbige Armbänder. Die Grade sind: Rot, Orange, Gelb, Grün, Blau, Weiß. Wobei der Weiße Grad ausdrückt, dass man die Prinzipien und Praktiken der unteren Ränge alle vereinigt. Was jedoch das besondere und wie ich finde auch gute an den Graden des CCD-Systems ist, dass man sich nicht auf dem weißen Grad ausruhen kann, sondern dass man danach einfach wieder mit dem roten Grad weitermacht. Weil man erreicht eben nie die Stufe des Allwissenden sondern soll sich bewusst sein, dass das Leben ein ewiger Kreislauf von Lernen ist. Klingt spirituell ist aber eher sehr praktisch orientiert. Weil wir lernen eben jeden Tag hinzu.

Heute hatte ich einen interessanten Effekt in Bezug auf die Vererbung von statischen Klassenvariablen.

Gegeben sei folgende Klasse, welche einige Config-Daten halten soll:

abstract class Config
{
 
    private static $definitions = array();
 
    protected static function addDefinition ($key, $value)
    {
        self::$definitions[$key] = $value;
    }
 
    protected static function getDefinition ($key)
    {
        return self::$definitions[$key];
    }
}

Die Sicherheitsabfragen und Dokumentation habe ich zum einfacheren Verständniss mal entfernt. Dann haben wir zwei weitere Klassen, welche von unserer abstrakten Config klasse erben.

class Config_A extends Config
{
 
    public static function addA ($key, $value)
    {
        self::addDefinition($key, $value);
    }
 
    public static function getA ($key)
    {
        return self::getDefinition($key);
    }
}
 
class Config_B extends Config
{
 
    public static function addB ($key, $value)
    {
        self::addDefinition($key, $value);
    }
 
    public static function getB ($key)
    {
        return self::getDefinition($key);
    }
}

Nun bestücken wir unsere Klassen mal mit Daten:

Config_A::addA ('treiber', 'configA');
Config_B::addB ('treiber', 'configB');
 
echo Config_A::getA ('treiber');

Nun würde man erwarten, dass auch wieder ein ‘configA’ heraus kommt. Da die statische Klassenvariable jedoch in der abstrakten Oberklasse liegt verwenden beide Unterklassen die selbe Variable. Die Ausgabe lautet nämlich: ‘configB’.

Wie kann man das Dilema also Lösen? Mein erster Ansatz war: Wir verschieben die Variable in die Unterklassen.

abstract class Config
{
 
    protected static function addDefinition ($key, $value)
    {
        $definitions = self::getDefinitions();
        $definitions[$key] = $value;
    }
 
    protected static function getDefinition ($key)
    {
        $definitions = self::getDefinitions();
        return $definitions[$key];
    }
 
    abstract protected static function getDefinitions ();
}
 
class Config_A extends Config
{
    private static $definitions = array();
 
    protected static function getDefinitions()
    {
        return self::$definitions;
    }
 
    ...
}

Analog dazu wird Config_B implementiert.

Jedoch sind abstrakte statische Methoden nur in PHP 5.0.x und 5.1.x erlaubt. Eine weitere Lösung wäre es, aus den Klassen einfach Instanzklassen zu machen. Bei meinem Framework mag ich es jedoch lieber nicht so viele Objekte zum Konfigurieren umher zu jonglieren sondern einfach den Zustand des Systems mit einer statischen Klasse zu verändern.

Letztendlich habe ich folgende Lösung umgesetzt:

abstract class Config
{
 
    protected static $definitions = array();
 
    protected static function addDefinition ($class, $key, $value)
    {
        self::validateDefinitions($class);
        self::$definitions[$class][$key] = $value;
    }
 
    protected static function getDefinition ($class, $key)
    {
        self::validateDefinitions($class);
        return self::$definitions[$class][$key];
    }
 
    private static function validateDefinitions ($class)
    {
        if (! isset(self::$definitions[$class])) {
            self::$definitions[$class] = array();
        }
    }
 
}
 
class Config_A extends Config
{
 
    public static function addA ($key, $value)
    {
        self::addDefinition(__CLASS__, $key, $value);
    }
 
    public static function getA ($key)
    {
        return self::getDefinition(__CLASS__, $key);
    }
 
}

So das ist der erste Eintrag.

Noch ein Blog. Wozu? Die Geschichte dazu ist ganz einfach erklärt:

Vor kurzem bin ich auf die Clean Code Developer Initiative gestossen. Dabei geht es darum sich als Software-Entwickler auch weiter zu entwickeln und einen besseren Code zu erzeugen. Dafür gibt es verschiedene Ränge. Ich werde das ganze Projekt sicher noch in einem weiteren Artikel weiter beleuchten. Auf jeden Fall ist eine Regel des grünen Grades, dass man sein Wissen auch weitergeben soll. Dafür ist dieser Blog gedacht.

Ich möchte einige Erfahrungen aus meinem Projektalltag weitergeben und auch bestimmte Themen aus der PHP-Welt beleuchten oder einfach meine Gedanken dazu kund tun. Und auf diese Weise mit der Entwicklergemeinde in Kontakt treten.

Nun denn, dann bin ich mal gespannt was daraus wird