Lange habe ich auf dieses Buch gewartet, einige Monate musste es auf meinem Wunschzettel warten bis es dann endlich erschienen ist:

Obwohl mein Chef meinte, dass das Buch nichts für mich sei, ich würde daraus nicht viel Neues lernen, habe ich es trotzdem gelesen, schliesslich will ich darüber bloggen und es dem “richtigeren” Zielpublikum (vielleicht) näherbringen. Kent Beck hat 77 Patterns gesammelt und niedergeschrieben, die sich mit dem schreiben von Code befassen. Dabei handelt es von verschiedenen Bereichen, von guter Namensgebung bei Variablen bis zur Evolution von Frameworks.

Wer Kent Beck’s Bücher kennt der weiss, dass diese selten sehr lang sind, auch in diesem Fall bekommt jedes Pattern im Schnitt knapp zwei Seiten Text. Es sind aber auch keine Design-Pattern, weshalb es kaum UML-Diagramme und auch wenig Code zu sehen gibt. Ich bin mir auch nicht sicher, ob man wirklich alles ein Pattern nennen kann und es teilweise nicht einfach “Best Practices” oder sogar Grundlagen der OO-Programmierung sind. Beispiele hierfür sind die Pattern “Method Visibility” und “Overridden Method”. Trotzdem glaube ich, dass das Buch ideal für Neulinge (beispielsweise als Ergänzung zum Modul Programmieren 1 an der HSR) ist, wenn man zwar die Syntax seiner ersten Programmiersprache gelernt hat und auch was implementieren kann, aber sich trotzdem nicht sicher ist, ob das auch “richtig” oder gut ist was man da macht.

Ein weiterer, sehr wichtiger Aspekt (vielleicht sogar der wichtigste) von Pattern ist ja, dass sie Dingen einen Namen geben, so dass sich unter Entwicklern ein gemeinsames Vokabular bildet. Dafür ist das Buch sehr gut zu gebrauchen, allerdings auch nur, wenn die Teammitglieder die Begriffe auch kennen… *wink-mit-dem-zaunpfahl*

Eines meiner Lieblingspattern im Buch ist “Method Object”. Nehmen wir an, wir haben eine ziemlich lange Methode. Was kann man dagegen tun? Ja genau, “Extract Method”! Was aber, wenn man viele lokale Variablen hat und die Parameterlisten der neuen Methoden immer länger werden? Dann erstellt man am besten eine neue Klasse, welche die lokalen Variablen als Instanzvariablen besitzt, verschiebt die lange Methode in die neue Klasse und zerhackt diese dort ordentlich in kleinere Stücke und führt wenn nötig weitere Refactorings durch. Ziemlich schön, oder?

Auch “Rate of Change” finde ich sehr interessant, und bietet wohl einigen Diskussionsstoff. Beck schreibt nämlich:

All the fields in a single object should change at roughly the same rate.

Sobald dies nicht der Fall ist, oder die Lebenszeiten von Instanzvariablen einer Klasse unterschiedlich sind, sollte man das ganze wahrscheinlich in eine Hilfsklasse auslagern. Natürlich gibt es auch hier Ausnahmen, aber Grundsätzlich finde ich das keine schlechte Idee.

Noch ein Zitat, mit dessen Aussage ich aber ausnahmsweise mal nicht einverstanden bin:

Duplication isn’t evil, it just raises the cost of making changes.

Ja, das hat er wirklich geschrieben. Duplizierung soll nicht böse sein? Ha! Mit jedem Ctrl+V wird eine Katze getötet, oder wie das auch immer genau ist.

Also, insgesamt ein, wie erwartet, sehr gelungenes Buch, welches nicht nur für Anfänger ist und ich allen ans Herz lege.