Refactoring to Patterns | Joshua Kerievsky | Designänderungen nun kein Problem mehr


	Refactoring to Patterns \| Joshua Kerievsky

Bücher:

refactoring to patte...

	Refactoring to Patterns Joshua Kerievsky Addison-Wesley, München, 2006 - 384 Seiten Kundenbewertung:(3 Bewertungen) großes Bild anzeigen
	weitere Infos, Preis & Bestellmöglichkeit

Der Blick hinter die Pattern-Kulissen

Hier habe ich gefunden, was ich lange gesucht habe: den Blick hinter die Kulissen, eine solide Anleitung, wie ich Design Patterns (Entwurfsmuster) in existierenden Code geschickt und elegant einarbeiten und diesen somit verbessern kann. Das Buch zeigt, wie, wo, wann genau und wann keine Entwurfsmuster in der Praxis am besten eingesetzt werden. Die Autoren versuchen, plattformunabhängig grundlegendes Verständnis für gute Software-Entwicklung, guten Code zu vermitteln, um so die Wechsel-Beziehung zwischen Refactoring und Patterns besser verstehen zu können. Das Buch ist gut geschrieben, die deutsche Übersetzung gelungen und leicht verständlich zu lesen. Wer mit dem genialen Tool ?Entwurfsmuster" in der Praxis noch nicht so recht etwas anfangen kann, dem kann ich dieses Buch guten Gewissens ans Herz legen.

weitere Infos, Preis & Bestellmöglichkeit

Designänderungen nun kein Problem mehr

Die Verbindung von Refactoring, also der Verbesserung bestehenden Codedesigns, und Patterns, der klassischen Lösung für häufig vorkommende Designprobleme hat der Autor toll dargestellt. Das Buch zeigt anschaulich, wie Entwurfsmuster bei der Softwareentwicklung helfen können, ohne zuvor eine vollständige Designplanung vornehmen zu müssen. Umfangreich und ausführlich wird darauf eingegangen, wie Designpatterns entwickelt werden und dass sie nicht im Voraus in ein System hinein entworfen werden müssen, sondern mit dem Wachsen des Systems ausgebildet werden können.

Klar ist, dass Kerievsky die Kombination von Refactoring und Patterns, die Verbesserung des Designs von bestehendem Code durch patternorientiertes Refactoring und das Ermitteln der Codebereiche, die patternorientiertes Refactoring erfordern, zeigen will. Dies gelingt ihm in diesem Buch hervorragend. Und letztlich ist dem Leser in der Tat klar, warum die Verwendung von Patterns zur Verbesserung bestehenden Codes vorteilhafter ist als die frühzeitige Verwendung von Patterns in einem neuen Design!

weitere Infos, Preis & Bestellmöglichkeit

Durchaus nützlich !

Wer, wie ich, ein Fan schlechter Übersetzungen ist, wird mit dem vorliegenden Werk seine wahre Freude haben (Vorsicht Sarkasmus !).
Das fängt an mit den obligatorischen Zwangseindeutschungen englischer Fachbegriffe, geht weiter mit Inkonsistenzen in der Anwendung (Diagramme sind häufig gleichzeitig englisch und deutsch beschriftet) bis hin zu schlicht falschen (das Java Interface Serializable wird z.B. sinnentleert in Serialisierbar übersetzt) bzw. unverständlichen Übersetzungen.
Mein persönlicher Favorit ist diesbzgl. folgender Satz:"Es handelt sich um Patterns (Design Patterns von Gamma, Anm. R.), mit denen, in Richtung auf oder ohne die meine Kollegen und ich echte Projekte überarbeitet haben." Ach so !
Es ist daher überhaupt nicht verwunderlich, daß Niemand für die geleistete Arbeit mit seinem Namen einstehen wollte, die Übersetzung erfolgte nämlich recht anonym durch G&U.
Jetzt zum Buch. Insgesamt würde ich den Inhalt als wirklich brauchbar einschätzen, erst recht in Ergänzung zu Gammas "Design Patterns"; allerdings kocht Kerievsky auch nur mit Wasser.
So wirkt das Bsp. zum Refactoring "Kompositum durch Erbauer kapseln" doch recht gekünstelt. Nach der Anwendung hat er gerade mal ein paar Zeilen Code eingespart, dafür aber deutlich an Verständlichkeit eingebüßt, weil die neuen Funktionen Vieles implizit erledigen, was mir nicht ohne Weiteres akzeptabel erscheint. Auch die Aufteilung der Funktionalität des BUILDER-Patternelements Director auf Client und Builder, deutet für mein Empfinden eindeutig auf einen Fall von Overengineering hin, da anscheinend ganze Patternbestandteile obsolet sind. Doch gerade diese Art des Patterngebrauchs sollte durch Anwendung nachträglicher Refactorings eigentlich vermieden werden.
Ein ähnliches Problem gibt es auch bei "Singleton inline stellen". Nachdem uns der Autor mitteilt, daß viele Singletons überflüssig sind, auch wenn sie anfangs sinnvoll erscheinen, wie z.B. beim State-Pattern oder der Factory, setzt er dem Leser nachfolgend ein derart triviales Bsp. vor, wo, glaube ich, Niemand auch nur im Entferntesten annehmen würde, hier wäre dieses Pattern jemals angebracht gewesen. Wer ordnet bitte sehr ein Attribut einer Klasse A einer Klasse B zu, nur um dann später global auf dieses zugreifen zu müssen ? Das fällt wohl eher in die Kategorie "elementare Designfehler" als in den Bereich möglicher Designverbesserungen.
Auch das Beispiel des etwas eigenartig benannten Refactorings "Typenschlüssel durch Klasse ersetzen" hat mich nicht überzeugt. Im Grunde genommen geht es um die Ersetzung von Wertkonstanten durch Referenzkonstanten (und die damit einhergehenden typsichere Eingrenzung des möglichen Wertebereichs). Warum er das ausgerechnet an (final static) String-Konstanten demonstriert, bei denen es sich ja schon um Referenzkonstanten handelt, erschließt sich mir nicht unbedingt. Im Ergebnis erfolgt nur die Substitution des vorher (wie ich finde, fälschlicherweise) benutzten Wertevergleichs (String.equals(...)) durch einen Wertevergleich mit Referenzvergleichsemantik (Aufruf von "==" in Object.equals(..)) und der Leser stellt sich die berechtigte Frage, worin hier eigentlich die Verbesserung liegt, man hätte doch gleich einen Referenzvergleich durchführen können - eine Frage, deren Beantwortung uns der Autor leider schuldig bleibt. In meinen Augen gibt es für dieses Refactoring nur 2 sinnvolle Anwendungen: 1. wenn man verhindern will, daß Attributwerte einer Referenzkonstanten nachträglich verändert werden. Dann macht es Sinn, eine Wrapper-Klasse zu schreiben, die den Zugriff entsprechend steuert, und 2. wenn man den Sonderstatus der Konstanten durch Einführung eines speziellen Konstantentypen hervorheben möchte; ansonsten benutzt man gleich beliebige Objekte + Referenzvergleich und nicht den Umweg über "equals(...)". Beides wird von Kerievsky im Abschnitt "Motivation" jedoch nicht erwähnt.
Aber ok, die meisten Refactorings haben sicher ihre Daseinsberechtigung, auch wenn die Beispiele nicht immer gelungen erscheinen.
Ich bin mir aber nicht sicher, ob Kerievskys haarkleine Aufschlüsselung der Vorgehensweise beim Refactoring (also Schritt für Schritt als Pseudo-Algorithmus) wirklich die beste Alternative darstellt, um den Sachverhalt zu erklären. Das Ganze ist nicht universell einsetzbar (muß für jeden Anwendungsfall umgemünzt werden) und enthält letztendlich viele unbrauchbare Zwischenschritte, die den Leser nur unnötig verwirren (mußte öfter grübeln, obwohl mir der Ablauf generell klar war). Ein klar strukturiertes VORHER/NACHHER hätte hier eindeutig mehr gebracht, zumal Jeder selbst die Anzahl der dazu erforderlichen Umwandlungsschritte nach seinen Vorlieben festlegt.
Sauer aufgestoßen sind mir auch die oft fehlerhaften UML-Diagramme und da meine ich nicht die Darstellung komplizierter Sachverhalte, in denen sich vielleicht ein kleiner Fehler eingeschlichen hat; nein, ganz Rudimentäres wie z.B. Zustände in Zustandsdiagrammen oder Objekte in Sequenzdiagrammen werden schlichtweg falsch visualisiert. Wie das passieren kann, obwohl angeblich sogar Martin Fowler (Autor eines UML-Buches) gegengelesen haben soll, ist für mich nicht nachvollziehbar. Ich will aber nicht unfair sein und räume ein, daß das evtl. das Übersetzungsteam zu verantworten hat.
Fazit: Kauft das englische Original und nutzt es vor allem als Denkanreiz, weniger als Anleitung.
Übersetzung: 2 Sterne
Buchinhalt: 3.5 Sterne
macht insgesamt: 3 Sterne.

weitere Infos, Preis & Bestellmöglichkeit

Folgende Artikel könnten Sie interessieren