Buch-Rezension zu “Refactoring to Patterns”

“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 “Refactoring”

“Refactoring: Improving the Design of Existing Code” von Martin Fowler erschien 1999 bei Addison-Wesley. Mit diesem Buch gelang Fowler ein Standardwerk, dass trotz seines Alters nichts an Aktualität eingebüsst hat.

 
Was ist Refactoring?
Als Refactoring bezeichnet man die Verbesserung der Struktur von Programmcode bei der die Funktionalität nach aussen hin nicht verändert wird. Diese Restrukturierung dient einer besseren Lesbarkeit, besserem Verständnis und der Erhöhung der Wartbarkeit. Dadurch können Erweiterungen an bestehendem Code leichter und schneller eingefügt werden.

Fowler beginnt das Buch nach einer kleinen Begriffserklärung mit einem Beispiel zur Gebührenberechnung für ausgeliehene Videos. Dieser kleine Anwendungsfall zeigt schön wie man schrittweise mittels Refactoring die Qualität von Code erhöhen kann. Und es weckt das Interesse, mehr darüber zu erfahren.

 
Grundsätzliches über Refactoring
Wann soll man es nutzen und wo liegen die Grenzen? Dies versucht Fowler im zweiten Kapitel zu beantworten. Seine Antwort darauf lautet, dass man es eigentlich immer machen sollte. Es gibt zwar einige Ausnahmen (wenn z.B. ein Neuschreiben des Codes weniger Aufwand verursacht), doch in der Regel ist Refactoring eine sinnvolle und notwendige Tätigkeit.

Einige Refactorings sind für die Performance nicht gerade förderlich. Fowler empfiehlt erst den Code aufzuräumen und danach die Performance anzugehen. Der gesäuberte Code ist in der Regel einfacher und effektiver zu optimieren. Natürlich gilt auch hier, das man immer auch selber denken darf. Blind einem Refactoring zu folgen nur weil es im Buch steht macht keinen Sinn.

 
Tests sind wichtig
Nach einer kurzen Auflistung der grössten “Bad Smells” und wieso diese nach einem Refactoring rufen geht es ums testen. Um sicherzustellen das sich an der Funktionalität nichts geändert hat, sind Tests unverzichtbar. Dieses Sicherheitsnetzt gibt einem die Freiheit, ohne grosses Nachdenken über mögliche Konsequenzen das Refactoring durchzuführen. Muss man ständig jede mögliche Auswirkung bedenken, kann man kaum noch produktiv arbeiten. Hat man aber Tests, passen diese auf und liefern schnell eine verlässliche Bestätigung. Bevor man sich in die Arbeit stürzt, sollte man unbedingt ein wenig Zeit in gute Tests investieren – es zahlt sich sehr schnell aus.

 
Der Katalog
Fowler hat 72 Refactorings gesammelt und immer nach diesem Format beschrieben:

• Name: damit man eine Basis für die Kommunikation hat und unter der gleichen Bezeichnung auch das gleiche versteht
• Zusammenfassung: wozu dieses Refactoring dient.
• Motivation: eine ausführlichere Erklärung wann man dieses Refactoring anwenden kann und wann man es sein lassen sollte.
• Ablauf: eine Schritt für Schritt Anleitung um das Refactoring durchzuführen.
• Beispiel: ein möglichst einfaches Beispiel das beim Verstehen des Refactorings hilft.

Die Refactorings reichen vom sehr einfachen extrahieren einer Methode über Templates bis zu Design Patterns. Manche davon gehen auf Smalltalk zurück und waren schon seit mehr als einem Jahrzehnt bekannt, andere wurden erst von wenigen Leuten um Fowler herum verwendet.

Bei zahlreichen Refactorings gibt es auch eine Gegenaktion. Auf “Extract Method” folgt zum Beispiel “Inline Method”. Je nach Situation ist das eine oder andere Refactoring nötig um zu besserem Code zu kommen. Der Katalog hilft einem bei der Umsetzung, aber der Entwickler trifft die Entscheidung, welchen Weg er einschlagen will.

 
Fazit
Die Schreibweise von Fowler hat mir sehr gefallen. Ohne grosses Tamtam erklärt er das sehr wichtige Thema und regt zum nachdenken an. Bei diesem Buch machte ich häufig eine Lesepause um gerade gewonnene Erkenntnisse und Ideen aufzuschreiben.

Neben dem eigentlichen Thema lernt man auch sehr viel über Objektorientierung. Etliche Feinheiten von denen ich bisher das “wie” kannte haben dadurch nun eine ganz neue Erklärung für das “wieso” bekommen. Auch wenn die Beispiele in Java sind, so gelten diese fast vollständig auch für jede andere (Objektorientierte-) Programmiersprache.

Ich kann jedem Programmierer dieses Buch empfehlen – es ist definitiv ein “Must-Read”.

 
Zum Buch
“Refactoring: Improving the Design of Existing Code” von Martin Fowler, 1999 Addison-Wesley, ISBN 978-0-201-48567-7, 464 Seiten

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

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:

• Client-Server
• 3- und N-Tier
• SOA
• Event-Driven Architecture (EDA)
• Peer-to-Peer (P2P)
• Grid
• Web 2.0

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