Archiv

Posts Tagged ‘Architektur’

Buch-Rezension zu “Patterns of Enterprise Application Architecture”

21. August 2013 1 Kommentar

Patterns of Enterprise Application ArchitectureEgal mit was für einer Technologie oder Framework man sich beschäftigt, das Buch “Patterns of Enterprise Application Architecture” von Martin Fowler wird wohl ein Kapitel dazu beinhalten.

MVC? OR-Mapper? Lazy-Loading? Unit of Work? Layering? Session State? Oder braucht man Tipps zur Strukturierung von Geschäftslogik? Fast jedes Thema das man beim Schreiben von Geschäftsanwendungen antrifft wird in diesem Buch behandelt und dessen Platz im grossen Puzzle erklärt.

 

Teil 1: Eine Übersicht zu Geschäftsanwendungen und deren Problemstellungen

Auf rund 100 Seiten erhält man eine Übersicht über die einzelnen Teile die eine Geschäftsanwendung ausmachen. Die Problemstellung wird so erklärt das man auch als Einsteiger in dieses Thema problemlos folgen kann.

Neben einer Definition der Begriffe erfährt man wo die Herausforderungen liegen und wie man durch eine geschickte Wahl der passenden Entwurfsmuster den eigenen Code von den häufigsten Problemen fernhält.

Wer sich schon länger mit Geschäftsanwendungen beschäftigt kann diesen Teil getrost überspringen. Man wird die besprochenen Probleme schon selber oft genug erlebt haben und möchte wohl gleich zu den passenden Lösungen im 2. Teil.

 

Teil 2: Die Patterns

Die Muster sind thematisch geordnet und nehmen die Reihenfolge aus dem 1. Teil auf. Dies macht das Buch sehr angenehm zu lesen da man so auf ein wildes hin und her springen verzichten kann.

Jedes dieser Muster wird nach dieser Schablone erklärt:

  1. Welche Probleme lassen sich damit lösen
  2. Ein UML-Diagramm
  3. Detaillierte Erklärung wie das Pattern funktioniert
  4. Eine Empfehlung wann man dies einsetzen soll (und wann nicht)
  5. Weiterführende Unterlagen
  6. Ein Beispiel mit Code in C# oder Java

Der grösste Nutzen liegt aus meiner Sicht nicht bei der Vorstellung der Patterns an sich, sondern beim Auflisten der Vor- und Nachteile. Stösst man im Projekt an Grenzen kann man entweder alles umbauen oder hier nachschauen was Fowler für Anpassungen empfiehlt. Dabei aber unbedingt überprüfen ob die von Fowler erwähnten Einschränkungen nicht zu noch grösseren Problemen führen. Sonst steht man nach viel Arbeit wieder an der gleichen Stelle.

 

Katalog der Enterprise Application Patterns

Wie für die Refactoring-Patterns gibt es von Martin Fowler auch einen Katalog zu den Enterprise Application Patterns. Darin werden die Patterns mit einer kurzen Beschreibung und dem UML-Diagramm vorgestellt. Dies genügt um sich über die Patterns zu unterhalten, wer allerdings eine Anwendung bauen will wird nicht um das Buch herum kommen.

 

Fazit

Mit Ausnahme von REST erklärt dieses Buch alles was heute bei den meisten Geschäftsanwendungen zum Einsatz kommt. Dabei handelt es sich nicht um irgendwelche an den Haaren herbeigezogenen Spezialfälle, sondern um konkrete Lösungen zu konkreten Problemen.

Wenn man auch intuitiv auf zahlreiche Lösungen selber kommen kann ist dieses Buch doch eine sehr hilfreiche Sammlung. Dies vor allem da auch Alternativen gezeigt und Einschränkungen offen angesprochen werden.

 

Zum Buch

Patterns of Enterprise Application Architecture” von Martin Fowler, 2002 Addison-Wesley, ISBN 978-0-3211-2742-6, 560 Seiten, Englisch

Schlagworte: , ,

Von fachlichen und technischen Daten

31. Juli 2013 Kommentare aus

In einer Geschäftsanwendung werden vor allem fachliche Daten bearbeitet. Daneben gibt es aber eine ganze Reihe von technischen Daten (wie einer ID oder einem Erstelldatum). Diese beiden Arten von Daten können problemlos nebeneinander abgelegt werden. Sobald man allerdings beginnt die Grenzen zu verwischen fangen die Probleme an.

Bis sich die Auswirkungen dieser Vermischung bemerkbar machen kann man sich meist nicht mehr an die dazugehörigen Entscheidungen erinnern. So beginnt ein mühsames Suchen nach den Ursachen von teils äusserst seltsamen Fehlern.

Ich will gar nicht zusammenrechnen wie viele Stunden ich so verloren habe. Dabei waren es zu Beginn jeweils ganz kleine Entscheidungen die am Ende zu solchen Problemen führten. Wie klein die sein können soll das nachfolgende fiktive Beispiel rund um Auftragsformulare zeigen.

 

Wenn aus technischen Daten fachliche werden…

Meist beginnt alles mit einer kleinen zusätzlichen Anforderung. Neu soll beispielsweise das Eingangsdatum eines Formulars geführt werden. Man kann nun ein zusätzliches Feld “Eingang” anlegen oder den Wert ins Feld “Erstellt” hineinschreiben. Das ist ja für die Anwendung das gleiche, da alle Formulare beim Eintreffen erfasst werden.

Allerdings wird das Feld “Erstellt” durch die Anwendung hinweg immer als technisches Feld betrachtet das man weder auf der Oberfläche anzeigt noch irgendwie sonst verwendet. Damit ist es nun vorbei. Für das Objekt “Formular” wird das Feld “Erstellt” nicht nur angezeigt sondern auch noch gleich umbenannt – allerdings nur auf der Oberfläche. Und in den Reports. Und im Export. Und bei allen anderen zukünftigen Verwendungen dieses Objekts.

 

… und dies zu Problemen führt

Die Sonderregelung für “Formular” ist zu diesem Zeitpunkt schon aufwändig aber noch kein Problem. Dazu braucht es meist noch eine kleine Veränderung der Geschäftsabläufe, wie einer externen Erfassung der Formulare.

Um diese externe Erfassung zu ermöglichen kommt dann oft eine Excel-Liste als Transfermethode zum Einsatz. So müssen die externen Sachbearbeiter nichts Neues lernen und im Zielsystem wird eine kleine Importfunktion hinzugefügt. Soweit ist dies ebenfalls noch kein Problem. Doch was soll nun ins Feld “Erstellt” geschrieben werden? Das Datum an dem die Daten importiert wurden oder das Eingangsdatum?

Aus fachlicher Sicht muss das Eingangsdatum gesetzt werden, da sich zwischen dem Eingang und dem Import Preise verändert oder Fristen abgelaufen sein könnten. Aus technischer Sicht wird das Formular mit dem Import erstellt.

Das Problem ergibt sich sobald beide Sichten “ihr” Datum benötigen. Das technische Erstelldatum könnte beispielsweise für einen Report zur internen Kostenverrechnung dienen. Wird dieser Report nach Eingang aber vor dem Import der Formulare ausgeführt stimmen die Werte nach dem Import nicht mehr mit dem Datenbestand in der Applikation überein. Die importierten Formulare fehlen im Report, werden daher nicht verrechnet und Ende Jahr gilt es zu klären woher die Differenz kommt.

 

Ursachen

Bei den Fällen die mir bekannt sind war die Ursache oft eine verfrühte Optimierung oder der krampfhafte Versuch Diskplatz zu sparen. Weder der zusätzliche Speicherplatz noch der Aufwand ein Feld mehr anzulegen hätte man bemerkt. Im Gegensatz zu all dem Aufwand zum Aufspüren der fehlerhaften Auswertungen.

Bitte beachten: DRY (Don’t repeat yourself) gilt nur wenn es sich wirklich um die gleichen Dinge handelt. Andernfalls ist dies keine Repetition sondern erfüllt einen anderen (unabhängigen) Zweck.

 

Wie verhindern?

Im obigen Beispiel hätte man spätestens als die Importfunktion erstellt wurde die Datenfelder trennen müssen. Allerdings denkt in so einem Moment niemand an solche Zusatzaufgaben. Und nur um Daten genauer abzulegen will niemand all die Oberflächen und Reports anpassen.

Daher bin ich mittlerweile der Meinung dass bei den ersten Anzeichen einer fachlichen Verwendung der technischen Daten die Alarmglocken läuten müssen. Fängt man an bei einzelnen Objekten technische Felder einzublenden ist dies ein deutliches Zeichen das hier ein fachliches Feld fehlt. Der Aufwand dies jetzt gleich sauber zu lösen ist geringer als wenn man wartet bis dieses Feld überall verwendet wird. Und fehlt doch gerade die Zeit kann man immer einen entsprechenden Task eröffnen und im nächsten Sprint (mit zusätzlichen Informationen) beheben.

Dies gilt übrigens im gleichen Masse für fachliche Felder die technisch genutzt werden, auch wenn dieser Fall wohl weniger oft vorkommt.

 

Fazit

Das Single Responsibility Principle (SRP) gilt nicht nur für Klassen und Methoden, sondern auch für Daten. Bevor man für eine kleine Einsparung bei der Datenmenge anfängt Felder mehrmals zu verwenden sollte man sich über die möglichen Konsequenzen bewusst werden und darauf verzichten. Angesichts der aufwändigen Fehlersuche bezweifle ich das durch ein “eingespartes” Feld wirklich Kosten gespart werden können.

Schlagworte: , ,

Buch-Rezension zu “Domain-Driven Design”

3. Februar 2013 1 Kommentar

Domain-Driven DesignWenn man sich mit Behavior Driven Development (BDD) und dem Schreiben von Akzeptanztests beschäftigt stösst man immer wieder auf ein Buch:
Domain-Driven Design: Tackling Complexity in the Heart of Software” von Eric Evans.

Dieses Buch gilt weit herum als Standardwerk das man unbedingt kennen muss. Beim Lesen merkt man schnell das Evans sehr viel Erfahrung hat und weiss wovon er schreibt. Leider macht er dies so ausführlich dass man kaum vorwärts kommt. “Man müsse die Informationen herausschürfen” ist eine Bemerkung über dieses Buch die man beim Lesen im Hinterkopf behalten sollte.

 

Kernpunkte

Von all den Themen die Evans behandelt stechen für mich diese Punkte besonders hervor:

Mit Hilfe einer Ubiquitous Language (einer einzigen gemeinsamen Sprache) sollen alle am Projekt beteiligten Personen kommunizieren. Dadurch das alle die gleichen Begriffe benutzen können Missverständnisse und Übersetzungsprobleme (im Sinne von Fachspezifisch zu Technisch) früh erkannt werden oder entfallen ganz. Auch ist es für Entwickler einfacher sich an die Spezifikationen zu halten wenn die Objekte im Code gleich heissen wie in den Anforderungen und den Testszenarios.

Bei Refactoring denkt man meistens an einen technischen Vorgang um Code besser zu strukturieren. Neben diesem technischen Aspekt gibt es aber auch einen fachlichen. Evens zeigt bei „Refactoring Toward Deeper Insight“ auf wie man nach und nach das Domänenmodell um neue Erkenntnisse verfeinern kann.

Entwickelt man nach Model Driven Design darf das Modell nicht in einem Vakuum erstellt werden. Ist dieses Modell technisch nicht umsetzbar wird in der Entwicklung gezwungenermassen eine Lösung gefunden die davon abweicht. Damit verliert man alle Vorteile und muss ständig zwischen mehreren Modellen hin und her wechseln. Neben höheren Kosten leidet dabei auch die Kommunikation.

Bounded Context: Das eigene Domänenmodell kann noch so gut sein, wenn man es nicht abgrenzt fliessen die unterschiedlichen Konzepte der Umsysteme hinein. Evens zeigt eine ganze Reihe von Ansätzen um dies zu verhindern (wie das Pattern “Anticorruption Layer”).

Software-Entwicklung ist mehr als das Schreiben von Code. Es geht um das Lösen von Problemen. Damit man die passende Lösung finden kann ist eine Zusammenarbeit mit allen beteiligten Parteien nötigt.

 

Kritik

Die gleichen Namen und Bezeichnungen zu verwenden ist ein grosser Schritt in die richtige Richtung. Nur ist es damit nicht getan. Mir fehlt wie man auch zu einer gemeinsamen Bedeutung kommt und überhaupt die Wiedersprüche aufdecken kann. (Wenn alle von Autos sprechen, wie merkt man das der eine einen Golf meint und der anderen einen Ferrari?)

Die ersten beiden Teile sind sehr schwerfällig geschrieben. Immer wieder springt Evans von einer Idee zur nächsten und wieder holt dieses hin und her mehrmals. Würde dies aus unterschiedlichen Perspektiven geschehen wäre dies ein Plus fürs Buch. Leider sucht man die ganze Zeit nach den Unterschieden zum bereits behandelten und findet meist keine. Dies bremst den Lesefluss und schlägt auf die Motivation.

Anstelle der vielen Wiederholungen wären Beispiele zur technischen Umsetzung hilfreich. Statt so viel über Code zu sprechen hätte Evens diesen zeigen können – dies ginge schneller und hätte einen Praxisnutzen. So bleibt zu viel eine schöne Idee ohne Hinweis auf deren Umsetzung.

 

Alternative

Abel Avram und Floyd Marinescu sahen ebenfalls einige Verbesserungsmöglichkeiten und schrieben 2006 das Mini-Book “Domain Driven Design Quickly“. Auf rund 100 Seiten gibt es all die Konzepte aus dem Buch von Evans, ein Interview mit ihm und es hat noch Platz für Ergänzungen aus “Applying DDD” von Jimmy Nilsson.

Wer ins Thema DDD einsteigen will sollte sich erst einmal das PDF bei InfoQ herunterladen.

 

Fazit

Mit Domain-Driven Design wurden viele wichtige Ideen erstmals in Buchform veröffentlicht. Die darin behandelten Themen sind auch heute noch aktuell und ein Umsetzen der von Evens vorgestellten Ansätze würde so manches aktuelle Problem lösen.

Leider verzettelt sich Evans mit seinen Erklärungen und macht es dem Leser äusserst schwer diese Konzepte zu verstehen. Als Einstiegslektüre ins Thema DDD kann ich dieses Buch daher nicht empfehlen. “Domain Driven Design Quickly” ist dafür die bessere Wahl, da die gleichen Konzepte viel besser auf den Punkt gebracht werden.
Kehrt man nach diesem Umweg zu Evens zurück versteht man seine Ideen viel besser und erkennt dann auch was sonst noch alles für Informationen in diesem Buch stecken.

 

Zum Buch

Domain-Driven Design: Tackling Complexity in the Heart of Software” von Eric Evans, 2003 Addison-Wesley, ISBN 978-0-3211-2521-7, 560 Seiten, Englisch

Buch-Rezension zu “Building Enterprise Applications with WPF and the MVVM Pattern”

25. April 2011 3 Kommentare

Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern” von Raffaele Garofolo erschien im März 2011 bei Microsoft Press. Das MVVM Pattern ist für Silverlight und WPF Anwendungen schon fast ein Muss. Für den geringen Betrag von 15$ bekommt man ein gutes Buch zu MVVM.

 

Das Buch startet wie zu erwarten mit einer Einführung ins Model View ViewModel Pattern und dessen Abgrenzung gegenüber den sonstigen UI Patterns wie MVC oder MVP. Mit diesen Grundlagen ist man gerüstet um die einzelnen Schichten einer Anwendung anzuschauen. Vom Domänenmodell geht es über den Data Access Layer durch die Geschäftslogik zur Oberfläche der Anwendung.

Als Abschluss bietet das Buch eine kurze Übersicht zu MVVM Frameworks und Toolkits wie Caliburn, Prism, MVVM Light Toolkit oder Cinch.

Am Ende jedes Kapitels findet man ein grösseres Beispiel in dem die gerade beschriebenen Punkte zu einem realistischen Szenario verbunden werden. Dies sollte man unbedingt anschauen, da der Text im Kapitel selber wohl nicht jedem genügen wird.

 
Klein, aber fein?
Das Buch ist mit nur 224 Seiten recht dünn, behandelt aber dennoch eine grosse Anzahl von Themen. So kann vieles nur angeschnitten werden, für eine Vertiefung fehlt es an Platz. Wer hier eine detaillierte Einführung in Caliburn erwartet muss zwangsläufig enttäuscht werden.

Es gibt aber Themen wie das Repository- oder das Unit of Work Pattern, die mit ausreichendem Tiefgang beschreiben werden. Der Mehrwert dieses Buches liegt für mich beim kombinieren der einzelnen Themen und Ansätze zu einem Gesamtbild.

Im Grossen und Ganzen hätte der Verzicht aufs eine oder andere Toolkit oder Framework dem Buch wohl mehr Profil gegeben. Jetzt wird zwar jeder angesprochen, doch wer eine Empfehlung für ein spezifisches Produkt sucht wird enttäuscht.

 
Test-Driven
Garofolo legt sehr viel Wert auf die Testbarkeit der vorgestellten Ansätze. So findet man neben einer minimalen Einführung in Test Driven Development über das ganze Buch verteilt immer wiederkehrende Beispiele wie man in dieser Situation nun genau den Code testen kann. Diese Hilfestellung fand ich sehr gut und ich wünschte mir, dass mehr Autoren so viel Wert auf die Testbarkeit legen würden.

 
Downloads
Beim Link zu den Code-Beispielen gab es scheinbar einige Probleme. Der Source Code finden sich auf http://examples.oreilly.com/9780735650923-files/9780735650923_files.zip. Man könnte für die Zukunft noch die ReSharper-Dateien und Binaries weglassen, wodurch das Zip deutlich kleiner würde.

 
Fazit
Wer eine kurze und günstige Einführung ins MVVM Pattern sucht wird in diesem Buch das gewünschte finden. Man muss sich aber mit WPF oder Silverlight auskennen, denn dies ist keine Einführung in diese Technologien.

 
Zum Buch
Building Enterprise Applications with Windows Presentation Foundation and the Model View ViewModel Pattern” von Raffaele Garofolo, 2011 Microsoft Press, ISBN Print 978-0-7356-5092-3, ISBN E-Book 978-0-7356-4982-8, 224 Seiten, Englisch

Schlagworte: , , ,

Buch-Rezension zu “Dependency Injection in .Net”

23. Januar 2011 2 Kommentare

“Dependency Injection in .Net” von Mark Seemann erscheint 2011 bei Manning. Man bekommt das Buch aber bereits jetzt via MEAP. Da nur noch ein einziges Kapitel zu Spring.Net fehlt, wage ich mich bereits an eine Rezension.

Schon zu Beginn des Buches wird einem klar, dass man es hier mit etwas speziellem zu tun hat. Welches Buch zu irgendeinem IT-Thema beginnt mit einer Erklärung wie man eine Sauce béarnaise zubereitet? Man mag schon fast meinen Manning hätte die Bücher vertauscht, doch hat diese Einführung durchaus ihren Sinn.

Mark Seemann kocht gerne und sieht zwischen Dependency Injection (DI) und einer Sauce béarnaise parallelen: Bei beiden vermutet man es sei kompliziert und viele verzichten daher darauf. Die ersten Versuche können fehlschlagen, doch hat man mal den dreh raus wird man es überall anwenden können.

 
Klare Struktur
Will einem ein Buch beim Strukturieren der eigenen Programme helfen, so sollte es selber auch klaren Strukturen folgen. Dies gelingt „DI in .Net“ so gut, dass man die einzelnen Kapitel in beliebiger Reihenfolge lesen könnte.

Wer dem vorgegebenen Pfad folgt beginnt mit einer Einführung, lernt Patterns und wie man DI auch von Hand machen kann. Sind einem alle nötigen Abläufe bekannt, zeigt einem der letzte Teil die jeweiligen Vor- und Nachteile dieser DI-Container:

 
Patterns und Anti-Patterns
Im Kapitel zu Patterns werden einem die Anwendungsmöglichkeiten von DI in .Net gezeigt. Seemann bevorzugt ganz klar die Abhängigkeiten wie Konstruktor den Objekten zu übergeben. Geht dies nicht kann man auch über Properties die Werte setzen oder bei jedem Methodenaufruf einen entsprechenden Kontext mitgeben.

Bei jedem Pattern wird immer erst erklärt wie das Prinzip funktioniert. Anhand der .NET Base Class Library (BCL) wird dann gezeigt, wo dies von Microsoft selber umgesetzt wurde. So zeigt Seemann wo man dieses Konzept schon bei der täglichen Arbeit nutzt – ohne das man DI verwendet. Ein ausführliches Beispiel rundet die jeweilige Vorstellung ab.

Bei den Anti-Patterns läuft es ähnlich ab. Nach einer Erklärung was er unter diesem Pattern versteht beschreibt Seemann wieso dies ein Problem ist. Die kleinen Abkürzungen ziehen Probleme mit sich die zwar harmlos aussehen aber zu grossen Verrenkungen führen. Gut gemeint ist halt noch lange nicht gut gemacht – dies gilt auch für die Konzepte rund um DI. Die vorgeschlagenen Refactorings zur Korrektur fand ich sehr hilfreich und sind das Geld fürs Buch bei weitem wert.

 
DI und Manning – war da nicht schon etwas?
Vor ein wenig mehr als einem Jahr habe ich schon ein anderes Buch zu diesem Thema mit dem Titel “Dependency Injection” vorgestellt. Mein Fazit war damals durchzogen und ich schlug vor, auf eine 2. Ausgabe zu warten. “Dependency Injection in .Net” ist zwar nicht diese 2. Ausgabe, aber es erfüllt meine damals erhofften Verbesserungspunkte. Das Buch ist sehr angenehm zu lesen und bekommt die Prinzipien und Vorteile auf eine sehr einfache Art erklärt.

 
Trotz MEAP bereits jetzt kaufen?
In der Mitte Januar vorliegenden Version ist das Buch noch nicht ganz fertig. Laut der Übersichtsseite fehlen noch ein Kapitel, das Vorwort, die Danksagung und der Index. Auch im Layout wird es in den nächsten Monaten noch zahlreiche Änderungen geben. Mir hat das Buch in der aktuellen Form schon sehr geholfen. Mir gefällt es aber auch schon bei der Entstehung Verbesserungen anregen zu können (via Online-Forum).

Wer grossen Wert auf ein perfektes Layout legt, sollte lieber noch bis zur offiziellen Veröffentlichung warten. Diese ist derzeit für den Juni 2011 geplant.

 
Fazit
Das Buch bietet eine gute Einführung ins Thema Dependency Injection. Durch den Aufbau und die vielen Tipps und Tricks ist es auch für Leute geeignet die mehr wollen als nur eine Einführung. Ich kann das Buch daher ohne Einschränkung weiterempfehlen.

Ich gehe sogar soweit dieses Buch als „Must Read“ zu deklarieren. Die darin vorgestellten Konzepte und Ideen sind so grundlegend, das man als Entwickler nicht darum herum kommt.

 
Zum Buch
“Dependency Injection in .Net” von Mark Seemann, 2011 Manning, ISBN 978-1-935182-50-4, >500 Seiten, [Englisch]

Buch-Rezension zu “Refactoring to Patterns”

10. Juni 2010 1 Kommentar

Refactoring to Patterns” von Joshua Kerievsky erschien 2004 bei Addison-Wesley. Es verbindet die beiden Themen Design Patterns und Refactoring.

 
Voraussetzungen
Um mit diesem Buch arbeiten zu können, sollte man unbedingt “Refactoring” von Martin Fowler zur Hand haben. Kerievsky verweist bei den Refactorings fast immer auf Fowler [F]:

Now I apply Inline Class [F] …

Dies hat den Vorteil nicht noch einmal alle Refactorings aufschreiben zu müssen, mit denen Fowler ein ganzes Buch füllte. Dies bedeutet aber auch, dass man ohne “Refactoring” grosse Verständnisprobleme haben wird.

Bei den Design Patterns ist es ein wenig anders. Man sollte mindestens schon einmal von “Design Patterns: Elements of Reusable Object-Oriented Software” der Gang of Four (GoF) gehört haben. Ein ungefähres wissen was beim Pattern erreicht werden soll genügt um dem Buch folgen zu können. Wer allerdings verstehen will was der Sinn des entsprechenden Patterns ist, wird nicht um weiterführendes Material herum kommen.

 
Wieso Patterns?
In der Einführung darf ein Kapitel zum Thema Patterns natürlich nicht fehlen. Kerievsky räumt darin mit einigen Vorurteilen und festgefahrenen Meinungen auf. Es gibt viele Wege ein Pattern zu implementieren. Dies ist besonders erwähnenswert, da dies allzu oft bestritten wird. Aus platzgründen wurde bei der GoF jedes Pattern nur einmal erklärt. Dies bedeutet aber nicht, dass es nur einen einzigen richtigen Weg zur Umsetzung gibt.

Ein weiterer guter Tipp von Kerievsky ist unter “Patterns Happy” zu finden. Nur weil man sich mit Patterns beschäftigt und diese nun überall gerne einsetzen würde, sollte man dennoch erst einmal Nachdenken. Macht es hier wirklich Sinn? Gewinne ich wirklich etwas durch das Pattern? Stehen Aufwand und Ertrag sowie die Wartbarkeit in einem akzeptablen Verhältnis? Ein blinder Wettlauf um möglichst viele Patterns anzuwenden führt am Ende sicher nicht zu besserer Software.

 
Der Katalog
Der Katalog von Kerievsky umfasst 27 Refactorings. Diese sind auf einer höheren Abstraktionsebene als diejenigen von Fowler. Kerievsky zeigt wie man die Bausteine von Fowler so anordnen kann, das man etwas grösseres daraus machen kann.

Vom Format her orientiert er sich ebenfalls an Fowler. Neben Titel, Zusammenfassung, Motivation, Ablauf und dem Beispiel folgt aber noch Variationen. Dieser Abschnitt dient zum Aufzeigen von alternativen Umsetzungen.

 
Fazit
Kerievsky gelingt es sowohl Patterns mit Refactoring zu verbinden wie auch neue Ideen zu beiden Themen zu liefern. Stellenweise hätte ich mir mehr Informationen zu den Refactorings oder den Patterns gewünscht. Dies lässt sich aber in “Refactoring” und “Design Patterns” nachschauen.

Das Buch kann ich jedem empfehlen, der die beiden Themen zusammen bringen muss. Wer sich allerdings nur für Patterns oder nur für Refactoring interessiert, wird mit diesem Buch nicht viel anfangen können.

 
Zum Buch
Refactoring to Patterns” von Joshua Kerievsky, 2004 Addison-Wesley, ISBN 978-0-321-21335-8, 400 Seiten

Buch-Rezension zu “Systemarchitekturen für Verteilte Anwendungen”

19. November 2009 Kommentare aus

Die steigenden Anforderungen an aktuelle Software benötigen entsprechend flexible Lösungen. Herausforderungen wie Skalierbarkeit oder Ausfallsicherheit hofft man mit verteilten Systemen lösen zu können. Doch wo soll man starten? Was für Möglichkeiten gibt es und wie kann man die unzähligen Begriffe und Konzepte einordnen?

Diese und weitere Fragen versucht das Buch “Systemarchitekturen für Verteilte Anwendungen” von Jürgen Dunkel, Andreas Eberhart, Stefan Fischer, Carsten Kleiner und Arne Koschel zu beantworten. Eine kurze Einführung über Software-Architektur und eine Erklärung der grundlegenden Begriffe dient als Start in die Welt der verteilten Anwendungen.

Diese Konzepte werden im 2. Teil vorgestellt:

Um ein Gefühl dafür zu bekommen wird jeweils eine Erklärung des Architekturkonzepts, eine Übersicht zu den Realisierungsplattformen und Code-Beispiele geliefert.

Teil 3 behandelt die Auswahl einer konkreten Architektur. Die im zweiten Teil vorgestellten Konzepte werden wieder aufgenommen und auf die Anforderungen aus dem Softwarelebenszyklus hin untersucht. Dies umfasst die Problemanalyse, das Design, die Implementierung und Test, sowie den Betrieb und die Wartung.
Die Fallbeispiele aus der Praxis reichen vom LAMP-Stack über den PetStore von Java EE bis hin zum Grid des CERN für den LHC (Large Hadron Collider).

Als Abschluss dient ein Ausblick auf Software as a Service (SaaS), Virtualisierung und Cloud Computing.

 
Stärken und Schwächen
Ein so komplexes und grosses Thema auf weniger als 300 Seiten näher zu bringen ist eine grosse Herausforderung. Es gelingt den Autoren einem einen guten Überblick zu verschaffen und hilft dabei, die unzähligen Begriffe einordnen zu können. Die Stärken des Buches liegen eindeutig bei den allgemeinen Erklärungen.

Bei den konkreten technischen Umsetzungen fällt die Qualität aber stark ab. Die Code-Beispiele sollen zeigen wie das Beschriebene konkret umgesetzt wird. Allerdings sind diese viel zu kurz und wenn man sich nicht bereits mit dem Thema auseinander gesetzt hat wird man kaum verstehen, was da nun gezeigt wird. Die Seitenlangen XML-Dokumente helfen da auch nicht weiter.

Die Formatierung ist sehr gewöhnungsbedürftig. Alle Leerzeichen in den Strings werden konsequent markiert – auch dann wenn diese nur zum einrücken dienen und über die halbe Seite gehen. Dafür fehlt bei Befehlszeilen der Hinweis, dass der Zeilenumbruch dem Layout geschuldet ist und man den Befehl als eine Zeile eingeben muss.

Auch sehr gewöhnungsbedürftig ist die Art, wie auf weiterführende Literatur verwiesen wird. Als Beispiel die Einleitung des Architekturkonzepts der Grid Architekturen:

Als Geburtsstunde des Grid Computing wird üblicherweise das Jahr 1998 mit dem Erscheinen des Werkes [25] genannt.

Möchte man wissen welches Buch gemeint ist, bleibt einem nichts anderes übrig als zum Literaturverzeichnis zu blättern. Dies ist leider kein Einzelfall.

Die grosse Anzahl der Autoren bemerkt man bei den Erklärungen der Begriffe. Teilweise wird sehr grosszügig damit umgegangen und dann wiederum werden Abgrenzungen gemacht, die mit der Praxis kaum noch etwas zu tun haben.

Die Fallbeispiele sind eine Enttäuschung. Der LHC an sich ist spannend, doch wer braucht eine vergleichbare Lösung? Und ist die Demo-Applikation PetShop wirklich erwähnenswert? Mehr Beispiele aus der Praxis die einer grösseren Leserschaft bekannt sind (wie Amazon) hätten da besser gepasst.

 
Fazit
Das Buch ist gut geeignet um einen Überblick über das Thema der verteilten Anwendungen zu bekommen. Wer allerdings an der technischen Umsetzung interessiert ist, sollte sich nach einem anderen Buch umschauen.

 
Zum Buch
Systemarchitekturen für Verteilte Anwendungen, von Jürgen Dunkel, Andreas Eberhart, Stefan Fischer, Carsten Kleiner und Arne Koschel, 2008 HANSER, ISBN 978-3-446-41321-4, 293 Seiten

Schlagworte: ,
Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 297 Followern an