Wie sieht beim CakePHP MPTT die Datenstruktur aus?

Ich nehm nun als Beispiel die Abteilung Finanzen. Die IDs sind frei erfunden. Ich geh einfach mal davon aus, dass die Firma die ID 1 hat…
Bei CakePHP wurde für das Tree Behaviour folgende Datenstruktur angewendet:

Wozu wird die parent_id verwendet?

Um schnell alle Kinderknoten eines Knotens selektieren zu können, wurde die parent_id mit eingebunden. Für das native MPTT wird das nicht benötigt.
Wie du sehen kannst, handelt es sich bei der Abbildung in der Datenbank um eine flache Tabelle. Diese Struktur kann selektiert und in Arrays abgelegt durchlaufen werden.
Falls du mal einen etwas komplexeren Baum kreieren willst, dann mach das nicht von Hand. Du verzählst dich garantiert!
Es ist der Horror diese Datenstruktur “zu Fuß” zu befüllen.
Bei CakePHP übernimmt dies vollumfänglich das entsprechende Modell. Und das ist auch vernünftig so.
Diese Art von Bäumen abzubilden ist für den lesenden Zugriff sehr schnell. Das liegt daran, dass eine flache Hierachie hinterlegt wurde, die durch eine lineare Iteration durchlaufen werden kann.
Das Einfügen von neuen Knoten irgendwo im Modell bedingt jedoch einige Updates. Alle anderen Knoten müssen entsprechend angepasst werden. Somit ist diese Baumstruktur Darstellung nicht sehr sinnvoll, falls du viele Updates und Inserts hast.
Bei Organigrammen, Navigationen usw. werden die Daten jedoch häufiger gelesen als geschrieben. In solchen Fällen ist das MPTT eine coole Sache.

Fazit

Als ich meinen ersten Baum in CakePHP aufgebaut habe, bin ich fast verzweifelt. Das MPTT ist ein einfaches Pattern. Aber wenn man nicht weiß wie man es bedienen muss, oder wenn man glaubt man kann es von Hand betreuen, dann geht man unter. Die Befüllung sollte nur über entsprechende Automaten erfolgen.
Im täglichen Gebrauch ist dieses Pattern sehr angenehm zu verwenden. Seit ich dieses Pattern verwende, sind meine Navigationen deutlich dynamischer und einfach zu verändern. Natürlich nur über eine entsprechende Oberfläche

Ähnliche Beiträge

Was für Erkenntnisse habe ich heute?

Ich habe mittlerweile erkannt, dass ich am Wochenende am Barcamp in Dornbirn locker über die Modularisierung und Benutzung von bestehenden Systemen sprechen kann.
Am Beispiel des Newssystems müssen vermutlich nur

• Ein Endedatum, an dem die News (der Artikel) nicht mehr dargestellt werden darf.
• Eine einfache Eingabe für die News, also keine komplette WordPress Eingabe sondern wirklich nur Titel und Beschreibung sowie Start- und Endedatum.
• Einige Views, mit denen die News Einträge überall ohne das komplette WordPress Verhalten angezeigt werden können. Dies kann über RSS Feeds oder über explizit entwickelte Views erreicht werden.

Wie könnte man WordPress entsprechend einbinden?

Nichts leichter als das!
Wir nehmen eine Factory Klasse, die uns für die unterschiedlichen WordPress Versionen die entsprechenden Adapterklassen anzieht.
Auf diese Weise sind wir vom WordPress entkoppelt und erhöhen nicht die Komplexität bei einem Update.
Das Ganze könnte ungefähr so aussehen:

Ich erstelle einen Adapter, oder eventuell eine Fassade, mit der die Komponenten von WordPress oder BuddyPress an mein eigenes System angepasst werden.
Da sich während eines WordPress Updates die Schnittstellendefinition verändern kann, wird pro WordPress Version ein dafür notwendiger Adapter oder Fassade geschrieben.
Falls sich nichts ändert, kann natürlich der gleiche Adapter verwendet werden.
Über eine Fabrikklasse kann die im Moment aktive Adapterklasse instanziiert und zurückgeliefert werden.
Die Fabrikklasse kann relativ einfach die Version des aktuell verwendeten WordPress auslesen und entsprechend den richtigen Adapter zurückliefern.
Cool oder?

Wie sieht es mit der Komplexität aus?

Auf dem Fucamp in Furtwangen habe ich über Guggat emol Blog, viel Spaß beim Lesen! Über Links zu Artikeln freuen wir uns, jedoch bitte bindet nicht einfach unsere Inhalte in eure Seite ein, danke. Hinweis für Feedleser: Beiträge, die Quellcode enthalten sind auf der Webseite meist besser lesbar, als in einem Feed-Reader.
4e3744397ab2a417f811b29573bcbef4)]]> http://www.baldenhofer.eu/blog/it/factory-und-adapter-pattern-fuer-die-erweiterung-von-wordpress/feed 0 http://www.baldenhofer.eu/blog/it/design-pattern-it/adapter-pattern-als-antipattern http://www.baldenhofer.eu/blog/it/design-pattern-it/adapter-pattern-als-antipattern#comments Sat, 18 Apr 2009 06:24:01 +0000 Roland http://www.baldenhofer.eu/blog/?p=764 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.

Ähnliche Beiträge

• 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

Ähnliche Beiträge

Ähnliche Beiträge

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.

Ähnliche Beiträge

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.

Ähnliche Beiträge

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.

Ähnliche Beiträge

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

Ähnliche Beiträge

Ähnliche Beiträge

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:

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

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.

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.

Ähnliche Beiträge

Um mit dem Server kommunizieren (oder auf gut Schwäbisch schwätze) zu können, müssen wir uns ein XMLHttpRequest Objekt für Firefox, Safari usw. erzeugen und für IEs brauchen wir ein ActiveXObject. Weiterhin müssen wir eine Callback Funktion an dieses XMLHttpRequest oder ActiveXObject anbinden um die Rückmeldung des Servers verarbeiten zu können.

Ein möglicher Code könnte ungefähr so aussehen:

Diesen Code müssten wir immer in unsere Funktionen in so ähnlicher Weise reinfummeln. Wir hätten außerdem noch mit der globalen Variable diverse Schwierigkeiten. Stell dir vor du möchtest über die Fußballergebnisse auf der gleichen Seite chatten. Dann weist du unter Umständen nicht mehr, welche Antwort vom Server nun zum Fußball oder zum Chat gehört.

Facade Pattern hierfür verwenden

Wenn wir unseren Code nochmal anschauen, wäre eine Kapselung der ganzen Kommunikation gar nicht so schlecht.
Wir könnten den ganzen Kommunikations- und Webserver Rückmeldungskram in ein dafür vorgesehenes Objekt verbuddeln.
Diesem Objekt geben wir im Konstruktor mit, welche Callback Funktion wir aufrufen wollen und welche URL verwendet werden soll.

Wir kapseln also die ganze Komplexität des Serveraufrufs und können dieses Objekt immer wieder verwenden ohne die Details des Serveraufrufs zu kennen.

Wie wir diese Klasse aufbauen erkläre ich in einem nächsten Artikel.

Ähnliche Beiträge

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:

Ähnliche Beiträge