Guggat emol Blog » WordPress Themes putzen

WordPress Themes putzen

Roland — Wed, 29 Jul 2009 08:52:49 +0000

Wenn ich gerade mal nicht beim Arbeiten, auf unserer Baustelle oder am Schlafen bin fummle ich ein klein wenig an WordPress herum.
Ute hat mir den Auftrag erteilt ein aufgeräumtes, einfach zu verstehendes und für miradlo taugliches Theme zu erstellen.

Das sind ja nun drei Wünsche auf einmal gelle?

Ich bin also mal in ein WordPress Theme reingestiegen und wollte gleich wieder raus gehen.
Da drin findet sich ein buntes Gemisch aus HTML-Tags und PHP Code.
Ich war wirklich überrascht wie schlecht man solche Ansichten aufbauen kann.

Vollkommen unübersichtlich
Verwendung von PHP 4 Sprachbefehlen (if … : … endif)
Aufruf von diversen Helferfunktionen aus den unterschiedlichsten Bereichen
Wartbarkeit ist für diese Themes eher ein Fremdwort

So, nachdem ich erst einmal lauthals geflucht habe, habe ich mir überlegt was ich damit anfangen will.

Was habe ich zuerst gemacht?

Ich bin hingegangen und habe mir ein paar Helfermethoden erstellt.

Methode mit der ein dynamischer Text innerhalb eines zu definierenden HTML Tags ausgegeben wird.
Diese Methode kann mit ein paar Parametern aufgerufen werden und ich kann hiermit ca. 60% vom HTML Code aus dem Theme verbannen.
Methode mit der komplexe HTML Tags dargestellt werden können.
Um Listen usw. zu generieren, habe ich noch eine weitere Methode erstellt. Damit spare ich noch mehr HTML Code ein.
Methode um WordPress Funktionen zu rappen und Funktionen die keinen String zurückgeben dennoch in HTML Tags umzuwandeln.
Damit konnte ich dann ungefähr 90% aller HTML Tags aus dem Theme entfernen.

Was bringen diese Methoden?

Ich kann hiermit (fast) sämtlichen HTML Code aus dem Theme entfernen.
Das Theme beinhaltet eine Aneinanderreihung der darzustellenden WordPress Funktionen. Wenn diese Funktionen in richtiger Reihenfolge dort eingebunden werden, sind sie sehr einfach zu überschauen und zu verstehen.

Ich habe damit meinem Theme die Lesbarkeit enorm verbessert.

Was mach ich als nächstes?

Wenn ich wieder dazu komme, werde ich alle Theme Dokumente entsprechend umwandeln und dokumentieren.
Danach sieht die Welt mit WordPress gleich viel aufgeräumter aus.
Weiterhin möchte ich die letzten “Geheimnisse” des WordPress Aufbaus verstehen.
Was ich bisher gesehen habe ist, dass die einzelnen Funktionen nach Themengebieten geordnet in den einzelnen Dateien hinterlegt sind.
Die meisten Funktionen so gebaut, dass sie Strings ausgeben können oder direkt mit echo ihre Ausgaben in den Themes durchführen.
Leider ist das nicht ganz durchgängig. Einige Funktionen können nur Strings zurückliefern oder nur echo durchführen. Hier sehe ich eine ziemliche inkonsistenz des Systems.
Diese Inkonsistenz kapsle ich mit meinen Helfermethoden. Somit kann ich einigermassen gleichmässig mit den Funktionen umgehen.

Was halte ich zur Zeit von WordPress?

Nach anfänglichem Erschrecken habe ich feststellen dürfen, dass WordPress durchaus eine logische Struktur mit sich bringt. Bei vielen Architekturen sammelt sich der “Unsinn” in den Views. Das kommt oft vor, da die Anwender nicht wissen, wo sie ihre Funktionalität einfügen sollen.

Ich denke mal wenn die eigenen Themes sauber aufgeräumt sind, dann wird dieses System auch einfacher zu warten und pflegen sein.
Sobald ich weiter komme, werde ich euch darüber informieren.

Adapter Pattern als Antipattern

Roland — Sat, 18 Apr 2009 06:24:01 +0000

Falls nur eine Interface Erweiterung benötigt wird, um eine Funktion für weitere Zwecke zu verwenden, ist das Adapter Pattern ein Overkill. Sehr häufig werden Adapter eingeführt ohne über die hiermit generierte Komplexität nachzudenken.

Adapter für Adapter

Eine weitere Falle ist, wenn man einen Adapter für einen Adapter baut.
Einmal hatte mein Team ein Stück Code übernommen und wir haben uns über die extreme Verkettung von Klassen gewundert. Wir kontrollierten das und fanden heraus, dass FÜNF Adapter hintereinander geschalten wurden um Funktionswerte zu maskieren. In dem Fall kann ich vom Adapter Pattern wirklich nur abraten und ein Refacturing vorschlagen
Refacturing bedeutet hier, die fünf Adapter zu entfernen und die Interfaces aufzuräumen.
Übrigens, beim Aufräumen konnte mein Team die Anzahl der Klassen von über 500 auf ca. 300 reduzieren. Danach sah das ganze System relativ übersichtlich aus.
Wir waren sogar wieder in der Lage die Komplexität zu überschauen und eine gewisse Stabilität zu erzeugen.

High Performance Anwendungen

Wenn du eine extrem stark beanspruchte Komponente hast, ist das Adapter Pattern auch keine gute Lösung. Zum Beispiel in Realzeitsystemen blockiert dir der Adapter die Verarbeitung. Du kannst meistens nicht genau sagen wie lange ein Aufruf und die Initialisierung des Adapters dauert. Er erhöht die Komplexität des Systems und kann dir somit ziemlich viele Schwierigkeiten machen. Also sei bei Realzeit- oder Komponenten die extrem häufig verwendet werden, mit Adaptern vorsichtig.

Adapter Pattern Einsatzbereiche

Roland — Wed, 15 Apr 2009 08:59:51 +0000

Das Adapter Pattern findest du an ziemlich vielen Orten. Immer dann, wenn ein “altes” auf ein “neues” System stößt und die Schnittstellen nicht zusammen passen wollen ist das Adapter Pattern, zusammen mit dem Facade Pattern einen Blick wert. Der Unterschied zwischen Adapter und Facade ist, dass eine Facade Komplexität versteckt. Ein Adapter wird eigentlich immer nur auf eine Klasse angewendet und nur dazu verwendet eine Umwandlung durchzuführen.
Beispiele:

Umwandlung eines DOM XML Dokuments in ein JSON Array
Anpassung bestehender Interfaces um neue Klassen darauf zugreifen zu lassen.
Anpassung von Funktionsübergabewerten um z.B. mit weniger Übergabeparametern dennoch eine entsprechende Funktion aufzurufen

Adapter Pattern Deklaration

Roland — Fri, 10 Apr 2009 19:00:00 +0000

Das Adapter Pattern ist relativ einfach deklariert.
Unser Adapter muss zwischen die miteinander zu verbindenden Interfaces eingeschoben werden. Meistens muss es noch aktiv Daten anpassen, damit die unterschiedlichen Interfaces sich auch verstehen können.
Beispielsweise kann das eine Interface ein Datum in String Form liefern und die Consumer Klasse erwartet ein Datum im UNIX-Timestamp Format als Integer. Hier wird unser Adapter den String in einen Integer umwandeln und übergeben.

Du kannst Adapter immer nach diesem Strickmuster zusammenbauen.
Die klugen Menschen, die wikipedia befüllen, haben das Adapter Pattern noch etwas tiefgründiger beschrieben. Du kannst im Adapter Pattern Artikel noch mehr darüber erfahren.

Adapter Pattern Problemstellung

Roland — Tue, 07 Apr 2009 18:50:40 +0000

In unserer dreidimensionalen, normalen Welt, sind Adapter etwas völlig normales. Fahr mal in die Schweiz und versuch den Stecker deines Föns in eine Steckdose reinzuwürgen. Oder nehme den Fön mit nach England und versuch es mal da.
Unsere Stecker passen nicht in die Schweizer oder Englischen Steckdosen.
Und was haben die klugen Elektrotechniker mit dem Problem gemacht?
Richtig, sie haben in endlosen Stunden das Adapter Pattern erfunden
Sie haben für unsere Stecker einen Adapter gebaut der auf der einen Seite die Form (das Interface) unserer Steckdosen hat. Auf der anderen Seite haben sie einen Stecker (das weitere Interface) erstellt, dass in die Englische Steckdose reinpasst.

Schöne Geschichte und wozu braucht ein Informatiker einen Adapter?

Wenn wir uns nicht gerade in einem Schulungsblog aufhalten, bauen wir nicht alle Systeme selbst. Normalerweise möchtest du deine Klasse an ein schon bestehendes Interface anschließen. Und manchmal kommt es dann vor, dass die beiden Interfaces nicht die gleiche Definition haben. Du musst entweder dein Interface anpassen oder einen Adapter zwischen die bestehenden Interfaces einfügen.
Sehr häufig verbinden wir zwei schon vorhandene Applikationen miteinander. Die Applikationen wurden erstellt, die Interfaces deklariert und getestest.
Niemand möchte hergehen und zum Beispiel Microsoft Word Programmteile anpassen um eine Erweiterung für ein daran anzuschliessendes Archivsystem zu erstellen. Das wäre wirklich kontraproduktiv. Wir werden zwischen dem Archivsystem und dem Word einen Adapter einführen.

Observer Pattern als Antipattern

Roland — Fri, 03 Apr 2009 05:09:54 +0000

Mit dem Observer Pattern können wir die Observer bei Änderungen des Subjekts informieren. Das ist prinzipiell eine super Sache. Wenn du jedoch ein Subjekt mit hunderten von Observern verknüpfst, wirst du sehr bald Geschwindigkeitseinbusen erfahren.

Ein Beispiel aus meiner Spielkiste

Ich erstellte mal eine dynamische HTML Generierung, die bei jeder Änderung des Modells informiert wurde. Die Texte innerhalb der Modelle änderten sich beim Aufruf des betroffenen Anwendungsfalls mehrfach. Der Aufruf der Observer führte dazu, dass das zu generierende HTML Dokument mehrfach aufgebaut und verändert wurde. Und der Aufbau des HTML Dokuments führte zu einer grotten langsamen Reaktionszeit. Ich baute komplexe Tabellen mit dieser Vorgehensweise zusammen. Beim Aufbau der Tabellen ist mir dann das Gesicht eingeschlafen. Zu viele Mitteilungen können das System blockieren.

Welche Gegenmassnahme rettete mich?

Abhilfe fand ich, indem ich die Textänderungen erst in die Modelle einfügte und dann nach der vollständigen Bearbeitung die Werte aus den Modellen übernahm. Mein Observer Pattern war dann auf Stufe Anwendungsfall eingesetzt. Sobald der Anwendungsfall komplett abgearbeitet wurde, konnte ich mit einem einzigen Zugriff die komplexen HTML Tabellen aufbauen.

Tipp

Falls du viele Änderungen auf dem Subjekt hast, und dir die Geschwindigkeit in den Keller geht, solltest du die notify() Methode überdenken und eventuell eine andere Art der Benachrichtigung verwenden.
Design Pattern sind dazu da dir das Leben zu erleichtern. Ein geiles Design muss jedoch immer noch funktionieren.

Observer Pattern Deklaration

Roland — Wed, 01 Apr 2009 10:04:58 +0000

Im Observer Pattern Problemstellung habe ich über die Benachrichtigung des Observers durch das Subjekt erwähnt.
Lass uns das mal im Klassenmodell ansehen:

Da hab ich aber schön ein Klassenmodell aus dem Internet abgepinselt gelle?
Im Internet wimmelt es von diesen Diagrammen. Aber ich habe mich entschieden dieses Diagramm dennoch einmal mehr zu zeichnen.
Wie funktioniert das Ganze jetzt?
Wir haben eine Interface Deklaration, die uns eine Methode update() bereitstellt. Jeder Observer muss dieses Interface implementieren.
Auf der Subjekt-Seite wird normalerweise eine Basisklasse definiert, die folgende Methoden beinhaltet:

add

Fügt einen Observer (Beobachter) in die interne Liste hinzu. Die registrierten Observer werden später bei Änderungen aufgerufen.

remove

Ein zuvor hinzugefügter Observer wird wieder entfernt und nicht mehr informiert.

notify

Wenn eine Änderung im Subjekt stattgefunden hat, wird mit notify jeder Observer über diese Änderung informiert.

Sequenzdiagramm zum Observer-Pattern

Um den Ablauf ein bisschen besser verstehen zu können, habe ich hier ein Sequenzdiagramm gemalt.

Zuerst registriert sich der Observer mit add() am Subjekt.
Das Subjekt erfährt zwei Änderungen die es mit update() dem Observer mitteilt.
Mit remove() entfernt sich der Observer wieder vom Subjekt und keine weiteren update() Meldungen werden an den Observer übergeben.

Beispiel mit konkreten Klassen

Die in Observer Pattern Problemstellung gezeigten Klassen können in unserem Observer Pattern wie im Folgenden gezeigt eingebaut werden.

Die einzelnen Observer (View Klassen) registrieren sich jeweils mit add() am Subjekt. Das Subjekt informiert die Observer über die update() Methode, wenn sich etwas im Subjekt verändert hat.
In diesem Demo habe ich immer noch die Observer und das Subjekt direkt miteinander verbunden. Wie bei Gegen Interfaces Programmieren festgestellt, sind wir mit dieser Lösung noch nicht voneinander entkoppelt. Das Observer Pattern beschreibt nur die Registrierung der Observer und die Mitteilung bei Subjektänderung an die Observer. Die Entkopplung von Subjekt und Observer findet nur in soweit statt, dass die Observer sich hinter einem Interface verstecken.

Observer Pattern Problemstellung

Roland — Tue, 31 Mar 2009 07:13:30 +0000

Stell dir vor du baust ein Modell um zu einer Person bestimmte Daten abzuspeichern.
Um die Daten des Modells schön darstellen zu können erstellst du diverse Ansichst (View) Klassen.
Jetzt musst du irgendwie auf die Personendaten zugreifen können.
Wir könnten also einen Unsinn, wie hier dargestellt, erstellen:

Superdoof oder?
Ich habe mich ja im Gegen Schnittstellen (Interfaces) Programmieren schon ziemlich über solche Konstrukte ausgelassen gelle?
Aber in dem Fall ist es noch schlimmer. Wir haben nicht nur gegen konkrete Implementierungen programmiert, nein wir haben uns auch noch ein paar andere Schwierigkeiten eingehandelt.

Keine Benachrichtigung bei Datenänderung

Unser PersonenModell lebt ein einsames und langweiliges Dasein.
Immer wenn jemand etwas von ihm will, wird es aufgerufen. Es kann sich nicht mit den anderen Objekten unterhalten.
Vermutlich wird es vereinsamen und den Job wechseln
Spaß beiseite. Ein Problem ist, dass bei einer Veränderung der Personendaten die umliegenden Objekte nicht informiert werden. Wenn also das EditPersonView Objekt Daten an das PersonModell Objekt übergibt, werden die ListNamesView, ShowPersonView und ShowPersonAgeView Objekte davon nicht informiert.
Wir könnten natürlich hergehen und unsere Objekte dazu verdonnern, alle paar Sekunden auf das PersonModel zuzugreifen.
Aber zum Einen kriegen wir so keine sofortige Information von einem Change mit und unser Overhead im Aufrufen wird relativ massiv. Wir verbrennen kostbare CPU Zeit.

Keine Entkopplung der Systeme

Ok, wir programmieren nicht nur nicht gegen Interfaces sondern können unsere Daten und Ansichten nicht voneinander trennen. Falls wir das PersonModell mal austauschen wollen, muss das in allen darauf zugreifenden Objekten bekannt gemacht werden.
Das wird richtig lustig, wenn du dann den Code von deinem Kollegen übernehmen darfst. Du wirst ihn für solch einen Pfusch lieben

Was macht das Observer Pattern besser?

Mit dem Observer Pattern werden die Modelle von der Ansicht entkoppelt.
Die Ansichtsobjekte (die Observer) registrieren sich an dem zu überwachenden Modell (dem Subjekt).
Observer wird in Deutsch als Beobachter übersetzt. Die Ansichtsobjekte beobachten somit das Subjekt.
Immer wenn eine Eigenschaft sich im Modell ändert, wird diese Information den
registrierten Observer mitgeteilt.

Hier noch zwei Links die Observer etwas detaillierter erklären. Ich werde natürlich noch die Deklaration und die mit Observer möglichen Antipattern erläutern.
Observer Wiki
Schöne Seminararbeit zu diesem Thema

Wann wird das Fassaden Pattern zum Antipattern?

Roland — Fri, 27 Mar 2009 04:57:44 +0000

Schade, jetzt haben wir endlich mal ein Pattern gesehen mit dem man komplizierte Sachen verstecken können und ich möchte schon wieder meckern
Wie bei allen schönen Sachen im Leben machen Fassaden Pattern manchmal ziemlich dick.
Wenn du in deinen Programmen alles kapselst und hinter eine Fassade versteckst, wirst du vor lauter Fassaden den Programmcode nicht mehr finden.
Es ist zwar prinzipiell gut, komplexe Abläufe zu kapseln und zu verstecken, doch auch hier sollte mit Vorsicht herangegangen werden.
Mach nie zu viele Fassaden. Sie sollten wirklich komplexe Abläufe und die dazugehörigen Objekte verstecken. Und es sollte auch nur dann gemacht werden, wenn du die Fassade öfters verwendest. Ein schlecht strukturierter Code wird durch eine Fassade schlussendlich nicht besser lesbar.
Ich hatte einmal in einem online Webshop in der Mitte eine Riesenklasse, die alle anderen Klassen versteckte. Nach einer Weile mussten wir immer mehr Fassaden um die Fassaden herumwickeln um an die benötigte Funktionalität heranzukommen. Wir bauten einen sogenannten Lava Code. Das bedeutet, dass wir immer mehr alten, nicht mehr benötigten Code, hatten. Niemand traute sich jedoch an den alten Code heran, da jeder befürchtete, dass der Code nicht mehr richtig funktioniert wenn wir ihn ändern. Stattdessen wurden weitere Fassaden eingebaut.
Wenn dir so etwas über den Weg läuft gibt es nur eines:
Aufräumen.
Putze deinen Code, kontrolliere was du wie anders kapseln kannst und geh mit Revers Engineering an die Sache heran. Ansonsten wird es wirklich hässlich.

Asynchrone Kommunikation mit JavaScript und Facade Pattern

Roland — Thu, 26 Mar 2009 05:18:02 +0000

Bei AJAX muss, unter Anderem, eine asynchrone Kommunikation mit dem Server stattfinden. Sonst ist es ja kein Asynchronous JavaScript and XML
gelle?

Man kann nun die Kommunikation ziemlich mies in jedes JavaScript reinwursteln und so eine Kommunikation mit dem Server anfangen.

Man kann aber auch die Komplexität dieser Kommunikation vor dem eigentlichen Entwickler verstecken und das Fassaden Pattern anwenden.

Ich habe hier ein Beispiel zusammengebaut bei dem du mit folgenden JavaScript Code eine Kommunikation mit dem Server durchführen kannst:

/**

* Ruft den Server auf um ihn um eine Antwort zu bitten.
*/
function onInitialLoad(){
this.asyncCommunication = new AsyncCommunication(showHello);
document.getElementById("message").innerHTML
= "Der Server sagt noch nix";
asyncCommunication.callServer("http://www.baldenhofer.eu/programmieren/serverResponse.php");
}
/**
* Callback Funktion.
*/
function showHello(){
request = this.request;
document.getElementById("message").innerHTML
= "Der Server sagt: "+request.responseText+" zu dir";
}

In diesem Beispiel wird eine HTML Seite erwartet in der irgendwo ein Element mit der ID message vorkommt.
Wenn das Dokument geladen wird, habe ich die onInitialLoad() Funktion aufgerufen.
Diese Funktion schreibt zuerst einmal in das message Element den Text “Der Server sagt noch nix”.
Weiterhin wird mit

this.asyncCommunication = new AsyncCommunication(showHello);

asyncCommunication.callServer("http://www.baldenhofer.eu/programmieren/serverResponse.php");

Auf dem Webserver ein Antwortdokument aufgerufen.
Damit das Ganze noch irgendwie einen dynamischen Text vom Server lädt, habe ich ein kleines Testscript mit dem fantastischen Namen serverResponse.php erstellt. Da drin steht ein echo “hallo Welt!”;
Der Server gibt also “hallo Welt” zurück.
Und wenn die ganze asynchrone Kommunikation klappt, wird die Callback Funktion showHello() aufgerufen.
Diese Funktion habe ich zuvor in der onInitialLoad beim Konstruktor mit übergeben.

Was haben wir jetzt davon?

Schau dir mal ein paar AJAX Kommunikationsbeispiele im Internet an. Du wirst tonnenweise Code usw. finden. Der Code ist relativ komplex und wenn er überall in deinem Programm dupliziert wird, nicht gerade wartungsfreundlich.
Ich habe den Code in einer Klasse gekapselt und somit die Komplexität auf diese Klasse reduziert. Immer wenn ich eine asynchrone Kommunikation mit dem Server durchführen will, kann ich diese allgemeingültige Klasse aufrufen und diese versteckt mir den komplexen Code.
Das bedeutet, diese Klasse bildet eine Fassade die mir die Komplexität versteckt.

Beispielcode für die Fassade

Hier ist der Beispielcode mit dem man die asynchrone Kommunikation durchführen kann.

/**

* Diese Klasse verwaltet die asynchrone Kommunikation zum Webserver.
* @param callBackFunc Die Funktion die nach der vollständigen.
* Übertragung vom Webserver aufgerufen werden soll.
*/
function AsyncCommunication(callBackFunc){
// Angabe, dass die Kommunikation zum Webserver vollständig
// abgeschlossen wurde.
this.READY_STATE_COMPLETE = 4;
// Angabe der callBack Funktion die bei Reaktionen vom Webserver
// aufgerufen werden soll.
this.callBackFunction = callBackFunc;
// Das Request Objekt
this.request = null;
}
/**
* Funktion um den gewünschten Request zum Webserver absetzen zu können.
* @param url Der URL, der aufgerufen werden soll.
*/
AsyncCommunication.prototype.callServer = function(url){
if(window.XMLHttpRequest){
this.request = new XMLHttpRequest();
}else if (window.AcitiveXObject){
this.request = new ActiveXObject("Microsoft.XMLHTTP");
}
if(this.request){
try{
var loader=this;
this.request.onreadystatechange=function(){
loader.callBack.call(loader);
}
this.request.open('GET', url, true);
this.request.send(null);
}catch(err){
alert("Webserveraufruf voll schief gange!");
}
}
}
/**
* Ruft nach der Rückgabe vom Server die zuvor deklarierte Callback
* Funktion auf.
*/
AsyncCommunication.prototype.callBack = function(){
if(this.request){
var readyState = this.request.readyState;
if(readyState == this.READY_STATE_COMPLETE){
this.callBackFunction.call(this);
}
}
}

Du siehst, innerhalb dieser Klasse habe ich die Initialisierung des Kommunikationsobjektes, die eigentliche Kommunikation und die Callback Funktion mit der Überprüfung der Rückgabewerte gekapselt.

Facade Pattern Problemstellung

Roland — Wed, 25 Mar 2009 07:43:31 +0000

Manchmal ist die Welt komplizierter als sie sein sollte.

Wenn wir zum Beispiel ohne Sinn und Verstand eine AJAX Kommunikation aufbauen wollen, dann würden wir alles in ein Script reinfummeln und müssten mehrere Funktionen hintereinander aufrufen. Ich habe hierzu einen kleinen Beitrag (AJAX Kommunikation ohne Fassaden Pattern) geschrieben.

Die Nachteile dieser Vorgehensweise sind:

Komplexe und ineinander verzahnte Funktionen müssen aufgerufen werden.
Jeder muss sich mit der Komplexität auseinander setzen
Die Kosten bei Wartung und Erweiterung sind hoch

Das Fassaden Pattern (Facade Pattern auf Englisch) schützt den einzelnen Programmierer vor der Komplexität.
Wir können eine einfach zu bedienende Schnittstelle erstellen. Diese Schnittstelle verbirgt das komplizierte System, dass wir ansonsten verwenden müssten.
Wir können somit komplexe Abläufe an einer Stelle einfach aufrufen. Es werden weniger Fehler beim Aufruf und Ablauf komplexer Abläufe entstehen. Und wir können die schwierigen Codeabschnitte kapseln. Dann brauchen wir nicht immer den besten Entwickler um kleine Änderungen am System vorzunehmen.
Hier eine kleine Grafik, die dass Fassaden Pattern darstellen soll:

Head First Design Patterns

Roland — Fri, 20 Mar 2009 23:49:42 +0000

Die Head First Buchreihe beschreibt in einer spielerischen Art und Weise die jeweiligen Themen. Ziel dieser Bücher ist es, dem Leser das jeweilige Themengebiet schnell und verständlich näher zu bringen.

Das Buch Head First Design Patterns von O’ Reilly (ISBN 0-596-00712-4) erklärt auf witzige Art- und Weise wie man Design Patterns verwenden kann.

Für wen ist dieses Buch geeignet?

Wenn du einen guten Überblick über die Standard Design Patterns erlernen willst, ist dieses Buch wirklich zu empfehlen.

Du solltest dich ein wenig mit Java oder C# auskennen. Dann kannst du die Programmbeispiele verstehen. Viel Programmiererfahrung brauchst du jedoch nicht.

Nach der Lektüre dieses Buchs wirst du den Ablauf und die Verwendung von Design Patterns verstanden haben. Es ist ein sehr gut lesbares und verständliches Lehrbuch.

Für was ist das Buch nicht geeignet?

Für die tägliche Arbeit mit Design Patterns ist dieses Buch nicht sehr sinnvoll, da die einzelnen Design Patterns durch Fallbeispiele erarbeitet und ziemlich ausschweifend ist. Eine Zusammenfassung der beschriebenen Design Patterns ist nicht vorhanden.

Themen des Design Patterns Buches

Folgende Design Patterns werden beschrieben:

Observer Pattern
Decorator Pattern
Factory Pattern
Singleton Pattern
Command Pattern
Adapter und Facade Patterns
Template Method Pattern
Iterator und Composite Patterns
State Pattern
Proxy Pattern
Compound Patterns (MVC usw.)

Nach dem Buch kannst du erkennen, welche Patterns du wann benötigst und kannst dich an das Designen von eigenen Applikationen mittels Pattern herantrauen.

PHP Design Patterns

Roland — Fri, 20 Mar 2009 12:44:41 +0000

Das Buch PHP Design Patterns von O’Reilly (ISBN-10 3-89721-442-3) behandelt die klassischen Design Patterns und wie sie unter PHP zum Einsatz kommen können.

Stephan Schmidt gibt einen Überblick wie in PHP die Objektorientierte Programmierung Einzug gehalten hat.

Dann beschreibt er diverse Regeln, die beim Software-Design eingehalten werden sollen.

Die einzelnen Design Patterns hat er in die Gruppen Erzeugungsmuster, Strukturmuster und Verhaltensmuster aufgeteilt. Komplexere Patterns hat er im Kapitel Enterprise Patterns beschrieben.

Bei der Beschreibung der Design Patterns hat er sich an die Standard Beschreibung von Design Patterns gehalten.

Er verwendet jeweils die Unterkapitel Motivation, Zweck des Patterns, Implemntierung, Fallstricke, Definition des Patterns, Konsequenzen und weitere Anwendungen.

Für wen ist dieses Buch?

Wenn du mit PHP Applikationen erstellen willst und ein sauberes Design anwenden willst, ist dieses Buch sehr hilfreich. Du kannst es während der täglichen Arbeit als Referenzbuch verwenden. Es beschreibt die einzelnen Design Patterns verständlich und ziemlich abschliessend. Mir hat das Buch sehr gut gefallen.

Für wen ist dieses Buch nicht geeignet?

Wenn du das erste Mal mit Design Patterns zu tun hast, ist dieses Buch ein wenig trocken. Zum Reinkommen in Design Patterns kann ich eher das Head First Design Patterns Buch empfehlen.

Guggat emol Blog » WordPress Themes putzen

WordPress Themes putzen

Was habe ich zuerst gemacht?

Was bringen diese Methoden?

Was mach ich als nächstes?

Was halte ich zur Zeit von WordPress?

Ähnliche Beiträge

Adapter Pattern als Antipattern

Adapter für Adapter

High Performance Anwendungen

Ähnliche Beiträge

Adapter Pattern Einsatzbereiche

Ähnliche Beiträge

Adapter Pattern Deklaration

Ähnliche Beiträge

Adapter Pattern Problemstellung

Schöne Geschichte und wozu braucht ein Informatiker einen Adapter?

Ähnliche Beiträge

Observer Pattern als Antipattern

Ein Beispiel aus meiner Spielkiste

Welche Gegenmassnahme rettete mich?

Tipp

Ähnliche Beiträge

Observer Pattern Deklaration

add

remove

notify

Sequenzdiagramm zum Observer-Pattern

Beispiel mit konkreten Klassen

Ähnliche Beiträge

Observer Pattern Problemstellung

Keine Benachrichtigung bei Datenänderung

Keine Entkopplung der Systeme

Was macht das Observer Pattern besser?

Ähnliche Beiträge

Wann wird das Fassaden Pattern zum Antipattern?

Ähnliche Beiträge

Asynchrone Kommunikation mit JavaScript und Facade Pattern

Was haben wir jetzt davon?

Beispielcode für die Fassade

Ähnliche Beiträge

Facade Pattern Problemstellung

Ähnliche Beiträge

Head First Design Patterns

Für wen ist dieses Buch geeignet?

Für was ist das Buch nicht geeignet?

Themen des Design Patterns Buches

Ähnliche Beiträge

PHP Design Patterns

Für wen ist dieses Buch?

Für wen ist dieses Buch nicht geeignet?

Ähnliche Beiträge