Refactoring Kata mit IntelliJ – Jason Gorman’s Assault Course

Vor kurzem habe ich mich dazu entschlossen, auf eine neue IDE umzusteigen. Da ich die letzten Jahre hauptsächlich mit Eclipse und NetBeans gearbeitet habe und wirklich jeder meiner Rock Star Programmer IntelliJ empfiehlt, war es höchste Zeit für mich, diese IDE einmal auszuprobieren. Da ich wirklich ein großer Eclipse Fan bin habe ich bis jetzt keinen sonderliches Verlangen danach verspürt, die Entwicklungsumgebung zu wechseln. Die große Anzahl an Shortcuts – ich steh besonders auf Strg + 3 – und die außerordentlich gute Integration von Maven mittels des m2eclipse-Plugin, machte Eclipse zu meiner absoluten Lieblings-IDE (zumindest bis vor kurzem).

Ich habe IntelliJ jetzt seit ungefähr zwei bis drei Wochen intensiv getestet. Mein Hauptaugenmerk lag dabei auf den Editor-Qualitäten, der Maven- und Groovy-Integration und bis jetzt bin ich absolut begeistert. Die Shortcut-Möglichkeiten sind um einiges ausgereifter als in Eclipse. Ich habe mittels Jason Gorman’s vor kurzem geposteten Assout Course, einige der tollen Refactorings von IntelliJ getestet. Der folgende Screencast zeigt mich beim Üben des Refactoring Katas in IntelliJ:

My version of Jason Gorman’s Refactoring Kata using IntelliJ

 

 

 

 

 

 

 

Zum Vergleich hier der Screencast von Jason Gorman mittels Eclipse:

Aussault Course by Jason Gorman using Eclipse

 

 

 

 

 

 

Den Source-Code des Kurses kann man hier downloaden.

Ich mache einige Dinge ein bisschen anders als Jason Gorman. Zum Beispiel führe ich Extract-Method-Refactorings immer von unten nach oben durch, da ich gerne meinen Source-Code von oben nach unten, d.h. alle Methoden in der entsprechenden Aufrufreihenfolge, organisiere. Das erlaubt mir meinen Quellcode wie ein Stückchen Prosa zu lesen. Diese Idee stammt übrigens aus Robert C. Martin’s Buch “Clean Code”.

Zuerst werden ein paar Methoden aufgrund von Verantwortlichkeiten in andere Klassen verschoben und extrahiert. Danach wird ein switch-Block durch den Einsatz des Strategy-Patterns ersetzt. Ich habe für das Projekt auch ein Github Repository angelegt. Von dort kann man den Ausgangszustand des Katas für IntelliJ clonen. Nachdem ich mit einem kompletten Durchgang fertig bin, “reverte” ich immer alle Files in den Ausgangszustand um das tägliche Üben zu erleichtern.

Fazit: IntelliJ rockt! Btw. Strg + 3 ist in IntelliJ Strg+Shift+A.

Advertisements
Veröffentlicht unter Kata, Programming, Refactoring | Verschlagwortet mit | Kommentar hinterlassen

IBM WebSphere Application Server v7 und EJB 2.1 / 3.0

In diesem Beitrag beschreibe ich, wie man ein einfaches EJB-Modul “from Scratch” erstellt und danach auf einem Application Server installiert. Hierzu verwende ich für die Entwicklung den Rational Software Architect in der Version 7.5.5.3 und den WebSphere Application Server in der Version 7.0.0.13.

Mein EJB-Modul wird ausschließlich aus einer Stateless Session Bean bestehen die einen einfachen String zurückgibt. Eine Einführung in die EJB-Technologie würde diesen Beitrag jedoch bei weitem sprengen. Jedoch gibt es eine Vielzahl von Online-Ressourcen die man sehr leicht “er-googlen” kann.

Folgende Dinge deckt dieser Blogbeitrag ab:

  • Die Erstellung eines einfachen EJB-Modules in der Version 2.1/3.0
  • Die Einbindung des Moduls in ein Enterprise Archive.
  • Das Deployment des EARs am Application Server.
  • Den Aufruf der Stateless Session Bean aus einem Standalone Java Client.

Im ersten Anlauf werde ich so ziemlich jeden Schritt bei meiner Vorgehensweise ohne Hilfe meiner IDE erledigen. Nur die Erstellung meiner Java Klassen werde ich im Rational Software Architect vornehmen. Auch das Exportieren der Jar Dateien werde ich dem RSA überlassen.

Der folgende Screencast zeigt die Erstellung des EJB v2.1 Projekts und das Deployment am Application Server durch Ausführung eines Jython-Administrationsskipts. Eine Stateless Session Bean, die ich als MessageServiceSLSB bezeichnet habe, retourniert einen einfachen String.

EJB v2.1 Projekt und Deployment am Application Server

 

 

 

 

 

 

IBM Spezifische Konfigurationsdateien

Um das EJB Modul erfolgreich am Application Server installieren zu können, muss man einige IBM spezifische Konfigurationsdateien zusätzlich erstellen.

ibm-ejb-jar-bnd.xmi: Diese Datei ist zwingend für ein erfolgreiches Deployment notwendig. In dieser werden die Bindungen der in der ejb-jar.xml definierten Elemente an die Ressourcen der Laufzeitumgebung eingetragen. Dazu gehören unter anderem die Abbildungen der einzelnen Ressourcen auf die JNDI-Namen innerhalb der Laufzeitumgebung oder die Abbildung der Sicherheitsrollen auf Elemente der Benutzerverwaltung.

ibm-ejb-jar-ext.xmi: In dieser Datei werden Einstellungen festgelegt, die das Laufzeitverhalten des WebSphere Application Servers beeinflussen, die die Standard EJB Spezifikation erweitern.

Im nächsten Screencast zeige ich die Erstellung einer simplen Standalone Java Client Anwendung, die den deployten Message Service aufruft. Dabei muss man folgende Dinge beachten: Der Client benötigt einige Bibliotheken um den Service erfolgreich aufrufen zu können. Deshalb muss man

  • die WAS v7 Runtime,
  • die notwendigen MessageService Interfaces plus deren generierte Stub-Klassen und
  • die Jar-Datei: “com.ibm.ws.admin.client_7.0.0.jar”

im Java Build Path der Client Anwendung hinzufügen. 

Die zuletzt genannte Datei befindet sich im Server (WAS v7)  Home-Verzeichnis im runtimes-Directory. Im Screencast habe ich dafür eine User-Library in der IDE angelegt um das Hinzufügen zu Projekten zu beschleunigen. Interessant ist auch, dass ich aus dem im zuvor gezeigten Video erstellen Enterprise Archive, alle Files bis auf die Interfaces und die zugehörigen Stubs aus der Jar Datei des EJB Projekts entferne, da sie von der Client Anwendung nicht benötigt werden.

Aufruf der Stateless Session Bean aus einem Standalone Java Client

 

 

 

 

 

 

Bis zu dieser Stelle im Beitrag habe ich ein EJB Modul der Version 2.1 in einem Enterprise Archive integriert, die notwendigen Stub-Klassen mittels ejbdeploy Kommando generiert und eine Client Anwendung erstellt, die den Service meiner installierten EJB Anwendung aufruft.

Erstellung einer EJB 3.0 Anwendung

Die folgenden beiden Screencasts zeigen im Prinzip genau das Gleiche wie die Vorherigen nur verwende ich EJBs in der aktuelleren Version 3.0. Der Unterschied besteht darin, dass für die Generierung der Stubs nicht mehr das Tool ejbdeploy.bat sondern createEJBStubs.bat zum Einsatz kommt. Wie bereits weiter oben erwähnt, gehe ich hier nicht auf die Technologie (EJBs) selbst ein. Dazu findet man ausreichend im Netz.

Implementierung eines EJB v3.0 Projekts und Deployment auf einem IBM WebSphere Application Server

 

 

 

 

 

 

 

 

Erstellung einer Standalone Java Anwendung die eine Stateless Session Bean aufruft

 

 

 

 

 

 

 

 

Mit diesem Blog wollte ich zeigen, wie einfach die Erstellung eines EJB Projekts und dessen Deployment auf einem WebSphere Application Server funktionieren. Natürlich muss man hierzu wissen, mit welchen Tools man die notwendigen Stubs generiert und wie man automatisiert EARs mittels Jython am WAS installieren kann. Dieses Wissen habe ich mir zum Teil über Schulungen, IBM Redbooks aber auch Internet Foren und der Hilfe von Kollegen angeeignet.

Ich werde in einem weiteren Blog erneut ein EJB Projekt (2.1/3.0) und eine entsprechende Standalone Client Anwendung erstellen, jedoch werde ich dafür erheblichen Gebrauch der Enterprise-Tools des Rational Software Architects machen. Dadurch werden einige bisher durchgeführten Schritte komplett transparent für den Entwickler und der Deployment Vorgang erheblich vereinfacht.

Veröffentlicht unter Development | Verschlagwortet mit , , , , , , | Kommentar hinterlassen

Personal Knowledge Base

In letzter Zeit kommt es des Öfteren vor, dass mich sowohl Arbeits- als auch Universitätskollegen nach meinen Quellen bezüglich aktueller Informationen betreffend meines Lieblingsthemas “Softwareentwicklung” fragen. Deshalb habe ich mich endlich dazu aufraffen können, eine Liste von Ressourcen zusammenzustellen, die ich hauptsächlich verwende.

Google-Reader (Blogs)

Ich benutze schon seit langer Zeit den Newsreader von Google (Google-Reader) und bin eigentlich recht zufrieden. Der Reader erlaubt es Blogs zu abonnieren und dann zu taggen, weiterzuempfehlen und in Verzeichnisse zusammenzufassen. Die folgende Liste enthält die von mir am meisten gelesenen Blogs:

Blogs meiner persönlichen “Rock Star”-Programmer
Blogs von Autoren
Blogs von IT-Seiten 
Blogs von Podcasts

Twitter

Wer glaubt auf Twitter nur sinnlose Statusnachrichten zu lesen, liegt gänzlich daneben. So ziemlich jeder meiner “Rock Star”-Programmer besitzt einen Twitter-Account. Die Möglichkeit über so genannte Hashes zu bestimmten Themen Nachrichten zu lesen, ermöglicht mir ständigen Informationsaustausch mit Gleichgesinnten. Sehr empfehlenswert dabei sind (wie war es anders zu erwarten): #goos, #tdd, #cleancode. Außerdem sind die meisten Personen äußerst hilfsbereit falls man etwaige Fragen zu bestimmten Themen hat. Erst heute habe ich mit Jason van Zyl (Maven) bezüglich der Erstellung von Maven 3 Plug-ins korrespondiert. Ich hatte einige Fragen betreffend der notwendigen Dependecies um Plug-ins erstellen zu können und er konnte mir diese sofort nennen.

Bücher

Ich werde hier jetzt nicht  anfangen Bücher aufzuzählen die ich für lesenswert empfinde… oder doch, eines werde ich erwähnen. Wenn man so wie ich, Interesse an Softwareentwicklung und Objektorientierter Programmierung besitzt, dann gibt es derzeit kein besseres, lesenswerteres Buch als: Growing Object-Oriented Software Guided By Tests. Ich habe bereits hier in einer dreiteiligen Serie darüber geschrieben.

Seit kurzem gibt es einen coolen Service: Any New Books? bei dem man sich registriert und dann zu bestimmten Themen via Mail Nachrichten über neue Bücher erhält.

Das Wichtigste dabei ist niemals aufhören zu lesen Winking smile

Groups

Natürlich dürfen Foren bzw. Groups in dieser Liste meiner Quellen nicht fehlen. Die folgenden zwei Groups befassen sich mit meinen aktuellen Lieblingsthemen.

Yahoo Test-driven Development Group
Google Growing Object-Oriented Software Group

Code-Sharing

Aktuell sehr beliebt ist auch GitHub. Hier findet man außerordentlich viele und oft sehr hilfreiche Quelltexte in jeglicher Programmiersprache. Wie bei Twitter habe ich auch bei GitHub alle meine “Rock Star”-Programmer finden und natürlich auch gleich “follow”en können.

Wie oft lese ich nun meine Blogs und Twitternachrichten? Täglich ca. ein bis zwei Stunden. Die wichtigsten Nachrichten speichere ich mir dann mittels Delicious-Bookmarks, die übrigens auch hier zu finden sind. Wenn ich nicht gleich Zeit finde, alle Neuigkeiten zu lesen, dann verwende ich hierfür Instapaper. Dabei handelt es sich im Grunde um eine To-Read Liste, bei der auch Beiträge archiviert werden können.

So, das war’s fürs erste einmal. Wenn mir noch weitere Quellen einfallen sollten, werde ich diese diesem Blog hinzufügen. Wenn mir jemand seine eigenen Quellen weiterempfehlen möchte, kann er diese gern in einem Kommentar zusammenfassen.

Veröffentlicht unter Resources | 1 Kommentar

GOOS – Gedanken und Zusammenfassung des zweiten Teils

GOOS – Blogeintrag 1

GOOS – Blogeintrag 2

TDD ist ja absolut keine neue Technik um Software zu entwickeln, meines Erachtens allerdings die einzig richtige Vorgehensweise, um auch über einen längeren Zeitraum ein Projekt wartbar zu halten. Damit meine ich nicht nur Bugs bereinigen, sondern auch neue Features hinzufügen. Wenn man es daher genau nimmt, dann wird ja ein Projekt ab dem Zeitpunkt des ersten Releases gewartet. Daher sollte man der Wartung besondere Aufmerksamkeit widmen.

Im zweiten Teils des Buchs beschreiben die Autoren ihre persönlichen Sichtweises bezüglich TDD und Objektorientierter Programmierung. Einige Dinge werden dabei immer wieder betont und wiederholt. Ich habe schon einige Bücher zur Objektorientierung und TDD gelesen, allerdings haben mich die Sichtweisen dieser beiden Autoren am meisten begeistern und überzeugen können. Das liegt zuletzt mit Sicherheit an der langjährigen Projekterfahrung der Autoren mit diesen Techniken. Wenn man selbst schon einige Erfahrung mit TDD machen konnte, hat man sich mit Sicherheit auch schon gefragt, wie man TDD bei größeren (Enterprise)Anwendungen einsetzen würde.

TDD für ein neues Projekt

image

Eigentlich freut man sich ja als Entwickler ein “Greenfield”-Projekt starten zu können. Aber wie setzt man TDD ein wenn noch absolut keine Infrastruktur vorhanden ist? Wenn man ein neues Feature beginnen möchte, dann fängt man ja mit einem Akzeptanztest (End-To-End) an. Ein solcher sollte so “End-To-End” wie möglich sein, d.h. Build, Deploy und Test sollte ebenfalls im Test beinhaltet sein. Doch beim absolut ersten Feature ist man sich der benötigten Infrastruktur noch nicht 100% sicher. Also wie kann ich dann mit einem Akzeptanztest beginnen, der so “End-To-End” wie möglich, allerdings noch keine Infrastruktur vorhanden ist?

Zu diesem Zeitpunkt führen die Autoren den Begriff des Walking Skeletons” ein. Dabei handelt es sich um die dünnste Schicht echter Funktionalität, die man Bauen, Deployn und Testen kann. Wichtig ist dabei, dass man dafür nicht zu viel Zeit verbraucht. Es sollte sich dabei mehr oder weniger um eine “Whiteboard”-Architektur der Anwendung handeln, die mit der Zeit natürlich wachsen und verbessert werden kann. Wichtig ist nur, dass alle Entwickler eine gemeinsames Verständnis der Architektur und der damit verbunden Infrastruktur entwickelt haben. Sauberkeit und Ausdrucksstärke des ersten Akzeptanztests, der diese Infrastruktur beinhaltet, ist dabei noch nicht so wichtig.

Dieses so genannte “Walking Skeleton” soll also gar nicht perfekt sein. Jedoch ist der dabei entstehende Lernprozess und das Feedback extrem wichtig für den Projektfortschritt. Okay, jetzt wissen wir also wie wir bei einem neuen Projekt mit Hilfe von TDD und mittels eines “Walking Skeleton” den ersten Entwurf unserer Architektur entwickeln. Wie geht es nun weiter? Wie halten wir diesen Prozess am Laufen?

TDD Prozess am Laufen halten

image

Grundsätzlich fängt man von Außen nach innen an. Für jedes neue Feature entwickelt man zuerst einen neuen  fehlschlagenden Akzeptanztest. Wichtig dabei ist, diesen Test möglichst technologieneutral zu implementieren, d.h. nur Ausdrucksweisen der Domäne zu verwenden. Der Vorteil von Akzeptanztest sollte bereits klar sein: Die Präzision Anforderungen in automatisierten Tests zu spezifizieren hilft implizite Annahmen zu vermeiden.

Ganz wichtig ist dabei auch die Trennung zwischen Unit Tests und Akzeptanztests, die ja den Projektfortschritt anzeigen und daher solange fehlschlagen sollten, bis das neue Feature fertig implementiert ist. Im Gegensatz zu Unit- und Integrations-Tests, die schnell und immer sauber sein sollten und dem Entwickler zur Unterstützung dienen.

Weitere wichtige Empfehlung der Autoren sind: Man sollte immer mit dem dem einfachsten erfolgreichen Fall anfangen (nicht mit Fehlerfällen) zu testen. Tests sollten so geschrieben werden, wie man sie selbst gerne lesen würde und Fehlermeldungen sollten solange verbessert werden, bis sie klar ausdrücken was schief gegangen ist. Außerdem sollten Testnamen das Verhalten des zu testenden Objekts im Kontext des Szenarios beschreiben indem es getestet wird.

 OO Style

image

TDD ist einer der beiden Techniken um Software möglichst wartbar zu gestalten, OOP ist die Andere. Allerdings weiß eder OOP-Entwickler, dass man bei dieser Art der Programmierung auch einiges falsch machen. Wie erreicht man also, das Code so einfach wie möglich gleichzeitig aber auch so wartbar wir möglich geschrieben wird?   Die Autoren erwähnen zwei Heuristiken um solchen Code zu schreiben und strukturieren: “Separation of Concerns” und “Higher Levels of Abstractions”. Kommen diese beiden Prinzipien zur Anwendung entstehen so genannte “Ports and Adapters”-Architekturen, wobei der Domänencode von technologieabhängigen Code getrennt entwickelt wird.

Ports sind Interfaces die die Beziehungen mit der äußeren Welt beschreiben. Adapters sind Brücken zwischen der Applikationsdomäne und der technischen Domäne. Diese Brücken implementieren die Interfaces die in der Applikationsdomäne definiert werden. Sie sind daher ein Mapping zwischen Domänen- und technischen Objekten. Zwei weitere wichtige Richtlinien sind die Kapselung und Information Hiding. Diese beiden gilt es nicht zu verwechseln. Kapselung stellt sicher dass das Verhalten eines Objekts nur über dessen öffentliche Schnittstelle beeinträchtigt wird und Information Hiding verbirgt wie ein Objekt sein Funktionalität hinter dessen Abstraktion der öffentlichen Schnittstelle implementiert.

Was ich im Buch auch immer wieder lese, ist die Wichtigkeit der dynamischen Struktur des Objektgeflechts. Die Kommunikation von Objekten und die dabei entstehenden Kommunikationsmuster sind das “Um und Auf”. Peers nennt man dabei die Nachbarn eines Objekts mit denen es kommuniziert, also Nachrichten sendet und empfängt. Dabei ist wichtig, dass ein Objekt nicht zu viel Interna preisgibt, da sonst der Client eventuell zu viel Arbeit übernimmt und dabei verteiltes Verhalten entstehen würde. Dabei handelt es sich natürlich um einen absoluten Wartungsalbtraum. Folgende Arten von Peers eines Objekts werden im Buch beschrieben: Dependencies, Notifications und Adjustments.

Dependecies eines Objekts bieten Services ohne denen das Objekt nicht seinen Verantwortlichkeiten nachgehen kann. Notifications sind Peers die über den Status des Objekts bescheid wissen müssen (“fire and forget”). Bei Adjustments handelt es sich um Peers die das Verhalten eines Objekts verändern, um den breiteren Anforderungen des Systems zu genügen.

Auch Composites und das gegenteilige Konzept dazu “Context Independence” wird im Buch näher beschrieben. Dabei betonen die Autoren, dass das API eines zusammengesetzten Objekts nie komplizierter sein sollte, als die der einzelnen Komponenten. Context Independence stellt fest ob ein Objekt zu viel oder die falschen Dinge verbirgt. Diese Technik angewendet, ergibt explizite Abhängigkeiten zwischen Objekten die jedoch nicht in den Objekten definiert werden (Factory Objects).

OO Design erreichen

image

Wie setzt man nun all diese Techniken und Prinzipien im Code um? Wie kann ich dies mittels TDD erreichen? Prinzipiell kann man sagen, dass ein Client immer wissen möchte wovon ein Objekt abhängt und was es tut aber nicht wie es etwas tut. Bei TDD schreibt man zuerst den Test, d.h. wir müssen uns darüber Gedanken machen, was wir erreichen wollen bevor wie wir wissen wie wir es erreichen.

Wichtig dabei ist, dass man den richtigen Level of Abstraction findet. Wenn die Absicht des Unit-Tests unklar oder nicht eindeutig ist, dann kann es sein dass wir eventuelle Konzepte vermischen. Dazu dient das Konzept des Information Hiding, also was kann die äußere Welt sehen. Durch einschränken des Scopes eines Unit-Tests kann auch verhindert werden, dass der Test zu lange und daher unsauber wird.

Wie bereits erwähnt, liegt der Fokus des Designs darauf wie Objekte miteinander kollaborieren um die gewünschte Funktionalität zu erreichen. Klassenstruktur ist auch wichtig, jedoch sollte die Hauptaufmerksamkeit den Kommunikationsmustern (=Kommunikationsprotokoll) gewidmet werden.

“Ein Interface beschreibt ob zwei Objekte zusammenpassen während ein Protokoll beschreibt ob zwei Objekte miteinander arbeiten können”

Eine weiterer Grund für unklare Tests kann eventuell das Preisgeben von zu viel Information der Implementierung eines Objekts sein. Das bedeutet, dass vielleicht die Verantwortlichkeiten zwischen dem Objekt und dessen Peers neu überdacht bzw. re-balanciert  werden müssen.

Weitere Abschnitte des Buchs behandeln das Finden von Value Types und Objekten. Dabei kommen folgende Techniken für  Value Types zum Einsatz: Breaking out, Budding off und Bundling up. DieseTechnik kann auch auf echte Objekte angewendet werden. Dabei handelt es sich beim Budding Off um ein so genanntes “On-Demand” Design. D.h., Interfaces und deren Implementierung werden aus der Sicht und Bedarfs des Client entwickelt anstatt auf Verdacht Features einer Klasse zu erstellen. Das vermeidet das Preisgeben von zu viel Information über die eigentliche Implementierung und somit wird die implizierte Kopplung minimiert und der Code bleibt formbar. Interfaces bezeichnen dabei Rollen die ein Objekt einnehmen kann und die Nachrichten die sie empfangen bzw. senden können.

Im dritten Teil des Buchs werden kommen nun alle Techniken anhand eines Beispiel-Projekts zum Einsatz. Bei einigen Dingen bin ich mir noch nicht ganz sicher, jedoch hoffe ich, dass mir der Code dabei helfen wird, die beschriebenen Prinzipien und Techniken noch besser zu verstehen.

Veröffentlicht unter Clean Code, GOOS | 4 Kommentare

New Conference Talks by Robert C. Martin

 

 

Veröffentlicht unter Clean Code | Kommentar hinterlassen

GOOS – Gedanken zum ersten Teil

Wow! Obwohl es sich beim ersten Teil doch eher um eine Einführung und Wiederholung der Themen TDD, OOD und Mocks handelt, habe ich eine Menge neuer Dinge gelernt. Bei einigen bin ich mir allerdings noch nicht 100% sicher, ob ich die Konzepte wirklich verstanden habe. Der erste Teil des Buchs besteht aus einer Einleitung, einem Kapitel über “What is the Point of TDD”, einem über “TDD with Objects” und ein kurzer Überblick der Tools die im Buch zum Einsatz kommen.

Objektgeflecht

In meinem letzten Blog-Post habe ich bereits über das Warum? bezüglich TDD geschrieben. Das darauffolgende Kapitel über “TDD with Objects” war äußerst interessant. Es betont die Wichtigkeit zu verstehen, dass es bei OOP nicht um die Objekte selbst sondern vielmehr um die Kommunikation zwischen diesen Objekte geht. Es entsteht ein Objektgeflecht, dass für das Verhalten des Systems maßgeblich verantwortlich ist. Dieses Verhalten kann man natürlich beeinflussen indem man dieses Netz aus kollaborierenden Objekten konfiguriert: Mit welchen Objekten ist ein Objekt verbunden; Objekte können ausgetauscht werden; Komplette Objektkompositionen können ersetzt und neu konfiguriert werden. Es handelt sich dabei um eine deklarative Vorgehensweise wie wir das Verhalten unseres Systems beeinflussen.

Objektgeflecht

Values und Objekte

Ich persönlich tue mir hin und wieder noch etwas schwer den Unterschied zwischen Objekten und reinen Werten zu unterscheiden. Auch hierzu bietet das Buch einen gesonderten Abschnitt zu dieser Thematik. Der Punkt, dass beide Varianten in vielen OOP Sprachen vom selben Konstrukt, nämlich einer Klasse, gebildet werden, trägt zum Verständnis nicht unbedingt bei. Eines ist jedoch ganz klar, wir teilen unser System in zwei Teile. Der eine Teil besteht aus unveränderlichen Werten und der andere aus Objekten die eine eigene Identität besitzen und somit den Zustand des Systems repräsentieren.

image

Kommunikationsmuster

Wie bereits erwähnt, ist die Kommunikation zwischen Objekten das wichtigste Konstrukt in einem OOP System. Die entstehenden Kommunikationspfade können mit Hilfe von so genannten Communication Patterns organisiert werden. Genau diese Muster bilden die eigentliche Domäne des Systems ab (im Gegensatz zum statischen Konstrukt der Klasse). Diese Denkweise ist auch für mich relativ neu und wird noch einiges an Übung erfordern um komplett von mir verstanden zu werden. Noch dazu wird das Domänenmodell verschleiert, da diese Kommunikationsmuster kein eigenes Konstrukt in einer derzeitigen OOP Sprache darstellen. Um diese Thematik besser verstehen zu lernen, wird auf das Buch von Rebecca Wirfs-Brock “Object Design: Roles, Responsibilities and Collaborations” verwiesen.

Tell, don’t ask!

Ein weiterer wichtiger Punkt ist das Law of Demeter bzw. der “Tell, don’t ask”-Style. Dabei geht es darum, dass Objekte aufgrund ihres eigenen Zustands Entscheidungen treffen sollen. Objekte sollten nicht aufgrund des Zustands anderer Objekte Entscheidungen treffen. Dadurch können “Train wreck” Konstrukte vermieden werden, was dazu führt, dass wir nicht nur Information Hiding unterstützen, sondern auch die Kommunikation zwischen Objekten explizit machen. Anders ausgedrückt, ein Objekt muss ganz genau sagen was es erreichen möchte und nicht wie.

Natürlich gibt es wie bei fast allen Richtlinien auch hier Ausnahmen. Das Abfragen von Werten oder Collections ist natürlich erlaubt. Hin und wieder müssen sogar richtige Objekte nach ihrem Zustand gefragt werden. Dabei sollte dem passendsten Objekt die Abfragemethode hinzugefügt und der Name der Methode so ausdrucksstark wie möglich formuliert werden. Solche Methoden sollten aber nur sparsam eingesetzt werden, da sonst das System unflexibel werden kann.

Mock-Objekte

Daraus folgt natürlich die Frage: Ok, ich soll also meinen Objekten sagen was sie tun sollen und nicht irgendwelche Eigenschaften abfragen. Aber wie teste ich dann ein Objekt das nur Kommandos besitzt und keine Rückgabewerte? Das ist der Zeitpunkt indem die Rolle der Mock-Objekte eingeführt wird. Im Buch wird das von den Autoren entwickelte Mocking-Framework JMock propagiert. Jedoch egal welches Framework verwendet wird, der wichtigste Punkt welcher beachtet werden sollte ist folgender:

Die Intention eines Tests sollte immer klar zum Ausdruck gebracht werden. Dabei muss eindeutig zwischen der zu testenden Funktionalität, der notwendigen Infrastruktur und der Objektstruktur unterschieden werden.

Veröffentlicht unter Clean Code, GOOS | Kommentar hinterlassen

Growing Object-Oriented Software (GOOS)

Nachdem ich mein letztes Buch (Softwaretests mit JUnit von Johannes Link) fertiggelesen habe und von der Materie einfach nur begeistert und überzeugt bin, habe ich beschlossen ein weiteres Buch, dass sich mit dem Thema TDD beschäftigt, zu lesen. Nur welches? Es gibt so extrem viele, die ich alle noch unbedingt lesen möchte, allerdings hat sich eines davon ganz klar abgesetzt, nämlich: “Growing Object-Oriented Software, Guided by Tests

So ziemlich jeder meiner Entwickler-Vorbilder, haben dieses Buch empfohlen. Man solle es allerdings nicht nur lesen, sondern die Vorgehensweisen der Autoren wirklich nachvollziehen und verstehen. Michael Feathers spricht von “Sate of the Art TDD”, Robert C. Martin sagt “This one’s a keeper” und noch einige mehr sind davon überzeugt, dass das Lesen und Verstehen dieses Buchs die eigenen Entwicklerfähigkeiten auf ein anderes Niveau anheben wird.

Fragen

Dieser Blog-Post soll keine Zusammenfassung des kompletten Buchs werden, sondern vielmehr einer von vielen, die meine Gedanken bezüglich der einzelnen Kapitel wiedergeben. Ich bin ja schon seit einiger Zeit überzeugter “TDDler” und doch stellen sich mir immer wieder Fragen wie z.B.:

  • Wie baut man ein größeres verteiltes System mittels TDD?
  • Wie viel wird vorab Designed?
  • Was bedeutet eigentlich die Phrase: “Die Tests treiben meine Entwicklung”?
  • Wie und wo fängt man eigentlich an?
  • Wie behält man bei einer großen Anzahl von Tests die Übersicht?
  • Wann ist man fertig?

Natürlich werden noch weitere Fragen auftauchen und hoffentlich mit Hilfe dieses Buchs beantwortet werden. Mittlerweile habe ich das erste Kapitel “What is the point of TDD?” fertiggelesen und bin begeistert. Es konnten schon einiger meiner Fragen zum Teil beantwortet werden. Wie in jedem von mir bereits gelesenen Buch zum Thema TDD, Clean Code und Refactoring, werden auch in diesem Buch diese Begrifflichkeiten im ersten Kapitel auf allgemeinster Ebene behandelt.

Testarten

Auch die Fragen wie TDD das Software-Design beeinflusst wird äußerst gut erklärt. Des weiteren findet man Definitionen zu verschiedenen Testarten wie z.B.: Unit-, Integration- und Acceptance-Tests. Allerdings handelt es sich dabei nicht um irgendwelche trockenen, schwer-verstehbaren Beschreibungen, sondern um gut erklärte, leicht nachvollziehbare Sichtweisen auf diese Themen.

Feedback

Die Autoren betonen auch immer wieder wie wichtig Feedback in der Softwareentwicklung heutzutage ist. Man sollte auf jeder Ebene, Mikro- also auch Makroebene, Feedback-Schleifen einbauen, um ständig dazuzulernen und das System wen nötig zu verbessern. Je früher man im Entwicklungsprozess Unklarheiten beseitigt und dadurch Fehler vermeiden kann bzw. aufdeckt desto billiger ist es natürlich auf diese zu reagieren und Verbesserungen vorzunehmen.

Akzeptanztests

Was für mich relativ neu war bzw. was ich nach lesen des ersten Kapitels dazugelernt habe, ist die Wichtigkeit des Akzeptanztests zu verstehen. Bevor man ein neues Feature in einem System hinzufügt, muss der dazugehörige Akzeptanztest geschrieben werden. Inwiefern dieser aussehen muss wird im Buch äußerst gut erklärt. Allerdings bin ich mir noch nicht ganz sicher wie ein solcher tatsächlich im Code festgeschrieben wird. Jedoch beinhaltet das Buch auch einen eigenen Teil wo ein kleines System entwickelt wird. In diesem wird mit Sicherheit auch mindestens ein Akzeptanztest geschrieben.

Qualität in Symbiose mit TDD

Meiner Ansicht nach trägt der Abschnitt über “External and Internal Quality” stark dazu bei, TDD zumindest einmal in einem Projekt ausgetestet zu haben. Es wird ausführlich beschrieben, wie TDD den geschrieben Code qualitätsmäßig in positiver Hinsicht beeinflusst. Wenn man seine Klassen testbar gestaltet, d.h.: man definiert klar die Abhängigkeiten und Verantwortlichkeiten dann erhält man automatisch eine besser Kopplung und Kohäsion seines Designs und ganz wichtig:

“TDD ist eine Technik um mit unvermeidlichen, unvorhersehbaren Veränderungen (in jeglicher Hinsicht) im Softwareentwicklungsprozess umzugehen”.

Also: “Never write new functionality without a failing unit test.”

Veröffentlicht unter Clean Code, GOOS | 2 Kommentare