Am Beispiel von CityBike möchte ich erklären, dass die Implementierung der Unit-Test’s jetzt ganz einfach geht. Wir haben also die leere Implementierung der Klasse:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class CityBike implements WithBasket {
 
    private Basket basket;
 
    public CityBike(Basket basket) {
    }
 
    public void addElement (Element e) {
    }
 
    public Basket getBasket () {
        return null;
    }
}

Alle Implementierungen sind leer, da wir ja im Sinne von Test-Driven Development (TDD) zuerst unsere Tests schreiben und erst danach die Implementierung. Hier also die JUnit4-Testklasse:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

import org.junit.Before;
import org.junit.Test;
import static org.junit.Assert.*;
import static org.mockito.Mockito.*;
 
public class CityBikeTest {
 
    private Basket basket;
    private CityBike cityBike;
 
    @Before
    public void setUp() {
        basket = mock(Basket.class);
        cityBike = new CityBike(basket);
    }
 
    @Test(expected=IllegalArgumentException.class)
    public void shouldNotCreateWithNullAsBasket() {
        new CityBike(null);
    }
 
    @Test
    public void shouldDelegateAddElementToBasket() {
        Element e1 = mock(Element.class);
        //
        cityBike.addElement(e1);
        //
        verify(basket).add(e1);
    }
 
    @Test
    public void shouldReturnBasket() {
        assertEquals(basket, cityBike.getBasket());
    }
}

Alle 3 Tests melden einen Fehler. Also ändern wir die Implementierung so, dass die Tests funktionieren:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public class CityBike implements WithBasket {
 
    private Basket basket;
 
    public CityBike(Basket basket) {
        if (null == basket){
            throw new IllegalArgumentException("null as basket not allowed");
        }
        this.basket = basket;
    }
 
    public void addElement (Element e) {
        this.basket.add(e);
    }
 
    public Basket getBasket () {
        return this.basket;
    }
}

Alle Tests funktionieren. (Die Implementierung und Tests für SimpleBasket und SimpleElement lasse ich hier im Text mal weg, damit es nicht zu unübersichtlich wird.) Damit haben wir als Programmierer von CityBike mal alles gemacht

Jetzt kommt ein zweiter Programmierer und möchte unsere Klassen benutzen. Es wird eine Person implementiert, die mit dem Fahrrad fahren soll. Allerdings muss dieser Fahrer seine Umhängetasche in den Korb (Basket) legen, bevor er losfahren darf. Natürlich sollte auch der zweite Programmierer seine Klassen “Fahrer” und “Tasche” testen. Hier die fertigen Implementierungen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

public class Fahrer {
 
    private Tasche tasche;
 
    private CityBike cityBike;
 
    public Fahrer(Tasche tasche, CityBike cityBike) {
        if (null == tasche){
            throw new IllegalArgumentException("null as tasche not allowed");
        }
        this.tasche = tasche;
 
        if (null == cityBike){
            throw new IllegalArgumentException("null as cityBike not allowed");
        }
        this.cityBike = cityBike;
    }
 
    void losfahren(){
        this.cityBike.addElement(tasche);
 
        // aufsteigen
        // nach rechts und links schauen
        // anfangen in die Pedalen zu treten
    }
}
 
public class Tasche implements Element {
 
    public int getWeight() {
        return 12;
    }
}
 
import org.junit.Before;
import org.junit.Test;
import static org.mockito.Mockito.*;
 
public class FahrerTest {
 
    private Tasche tasche;
 
    private CityBike cityBike;
 
    private Fahrer fahrer;
 
    @Before
    public void setUp() {
        this.tasche = mock(Tasche.class);
        this.cityBike = mock(CityBike.class);
 
        this.fahrer = new Fahrer(tasche, cityBike);
    }
 
    @Test
    public void shouldAddTascheInKorb() {
        //
        fahrer.losfahren();
        //
        verify(cityBike).addElement(tasche);
    }
}

Was passiert, wenn wir die Methode addElement(Element e) aus WithBasket und CityBike rausnehmen. Jeder der dann WithBasket, CityBike oder andere Subklassen von WithBasket benutzt muss dann den Wege über getBasket().add(Element e) gehen. Die Methode losfahren in Fahrer sieht dann so aus:

1
2
3
4
5
6
7

    void losfahren(){
        this.cityBike.getBasket().add(tasche);
 
        // aufsteigen
        // nach rechts und links schauen
        // anfangen in die Pedalen zu treten
    }

Aber nicht nur das wir jetzt in X Klassen dieses getBasket().add(tasche) stehen haben. Wir machen den Benutzern unserer Klasse auch noch das Testen schwieriger:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

import org.junit.Before;
 
import org.junit.Test;
 
import static org.mockito.Mockito.*;
 
public class FahrerTest {
 
    private Tasche tasche;
 
    private CityBike cityBike;
 
    private Basket basket;
 
    private Fahrer fahrer;
 
    @Before
 
    public void setUp() {
 
        this.tasche = mock(Tasche.class);
 
        this.cityBike = mock(CityBike.class);
 
        this.basket = mock(Basket.class);
 
        this.fahrer = new Fahrer(tasche, cityBike);
 
    }
 
    @Test
 
    public void shouldAddTascheInKorb() {
 
        when(cityBike.getBasket()).thenReturn(basket);
 
        //
 
        fahrer.losfahren();
 
        //
 
        verify(basket).add(tasche);
 
    }
 
}

Wir haben eine zusätzliche Membervariable basket im Test und der Test muss noch Vorbereiten das auf cityBike auch wirklich ein Basket geliefert wird. Und hier haben wir nur eine Verschachtelungstiefe. Man denke sich mal aus wie es aussieht wenn wir folgende Situation haben: A.getB().getC().getD().add(E e). Und jetzt stelle sich der Leser noch vor, dass das ganze Konsequent in der ganzen Applikation so gemacht wird. Irgendwann sind die Tests so aufwendig und kompliziert, dass kein Entwickler mehr Tests schreibt, weil einfach keine Zeit ist. Wenn dagegen immer das Law of Demeter eingehalten wird, dann sind die Tests kurz und einfach.

Schlusswort:

Ich habe hier Mockito verwendet um die Mock-Objekte zu schreiben. Eine wirkliche Empfehlung von meiner Seite. Diese Bibo ist der Hammer. Wirklich schnell zu lernen und eine wunderschöne API. Gratulation an die Entwickler zu diesem tollen Stück Software.

Schönes Wochenende!

Als heute  morgen alle noch bei Kaffee in unserem Pausenraum sassen, habe ich ein speziellen Teil unseres Domain Modells an die dort hängende Tafel gemalt. Ich wollte allen mitteilen, auf welch schönes Design wir gestern für einen Teil unseres Domain Modells gekommen waren. Insbesondere wollte ich auch aufzeigen, wie elegant eine Lösung werden kann, wenn man sich an das Gesetzt von Demeter hält. Dabei haben Jan und ich nicht mal an das Gesetz gedacht, als wir die Schnittstellen definiert haben. Es ist sozusagen “einfach entstanden”.

Hier ein leicht abgeändertes Beispiel:

Wir haben also ein Interface welches aussagt, dass ein Typ welches dieses Interface implementiert eine Has-A-Beziehung zu Basket hat. Ein WithBasket-Object hat also immer einen Basket. Ausserdem kann ein Basket eine Menge (0 bis n ) Elemente beinhalten. Nun machen wir mal zwei Methoden hinzu:

Die Diskussion entbrannte nun an der Methode addElement(Element e) in WithBasket. Eine Implementierung von WithBasket muss also diesen Aufruf an Basket delegieren. Und dieser Punkt war einigen Kollegen nicht geheuer bzw. wurde abgelehnt, u.a. mit der Begründung, dass ja der Typ WithBasket nicht für die Verwaltung von Elementen zuständig ist. Besser sei auf WithBasket eine Methode “public Basket getBasket()” zu implementieren, void addElement(Element e) wegzunehmen und der Benutzer von WithBasket kann dann auf dem Basket die gewünschten Operationen ausführen. In einem Client von WithBasket würde also folgender Code stehen:

myObjectWithBasket.getBasket().add(myElement);

Dies bricht das Gesetz von Demeter.

Nun habe ich in der Mittagspause nachgedacht und nach Beispielen aus dem realen Leben gesucht. Als Erstes ist mir ein Theaterbesuch in der ehemaligen DDR eingefallen. Dort habe ich mal Folgendes erlebt:

Vor der Garderobe des Theaters stand eine Angestellte des Theaters die offensichtlich für die Garderobe zuständig war. Als wir nun unsere Jacken abgeben wollten, zeigte sie mit dem Finger auf die Kleiderhaken und wir mussten nach hinten gehen und unsere Sachen selber aufhängen.

Es ist richtig, dass es nicht die Verantwortlichkeit der Garderobenfrau war, unsere Kleider die ganze Vorstellung lang zu halten. Trotzdem empfindet man dies doch als komisch. Ich bin jedes mal dankbar, wenn mir die Jacke abgenommen und an die Kleiderhaken gehängt wird. Dieses Muster findet man sehr oft vor. Ein weiteres Beispiel die die Essenbestellung im Restaurant. (Gast -> Bedienung -> Koch).

Ein weiters Beispiel ist die Rezeption im Technopark Zürich. Die Rezeption hat auch einen Kopierer und wenn man möchte, kann man dort auch Sachen kopieren lassen. Man gibt ein Blatt ab, die Frau an der Rezeption nimmt das Blatt, legt es auf den Kopierer und drückt den grünen Knopf. Es ist so viel angenehmer, als erst selbst hinter die Rezeption an den Kopierer gehen zu müssen. Was passiert aber, wenn ich den Kopierer viel besser bedienen kann, als die Frau an der Rezeption? Ich kenne das Teil und weiss, wie man die Graustufen einstellt und wie man verkleinert. In solch einem Fall wäre es eventuell doch nötig an den Kopierer heranzukommen.

Um wieder zum Basket-Beispiel zurückzukommen. Was macht man, wenn man nun Basket in einem GUI darstellen möchte und nur WithBasket hat?

Für die Darstellung von Basket breche ich nun die Kapselung. Nicht unbedingt 100% Law of Demeter aber pragmatisch. Oder?

Trotzdem stelle ich die wichtigen Operationen von Basket am WithBasket zur Verfügung, damit im Domain-Model immer über dieses gegangen werden kann. Und wenn ich getBasket weglassen kann, dann mache ich es auch. Schlussendlich entscheidet der fachliche Kontext in solch einem Fall.

Wie einfach die Unit-Tests dann auf einmal zu schreiben sind, kommt vielleicht ein anderes Mal. Heute bin ich zu müde…

Gute Nacht

Es hat funktioniert!

Leider habe ich erst heute Zeit gefunden, den Source auf bitbucket zu stellen. Es hat noch hässliche Sachen drin.  Mir ist es in der Klasse TeneoDirectory zum Beispiel nicht gelungen, die Transaktionen deklartiv einzubauen. Ich hole jetzt von der EntityManagerFactory einen EntityManager und von dort die Transaktion. Anders habe ich es einfach nicht hinbekommen… und irgendwann war die Zeit zu Ende.

Wenn jemand eine andere Lösung hat, bitte unbedingt melden.

SpringSource Enterprise Bundle Repository

Für OSGi-Liebhaber ist es sicherlich nett, dass die Jar’s dort alle OSGi-ready sind.

Dann habe ich mir noch die folgenden zwei Dateien für die Konfiguration von Ivy im Projektverzeichnis meines Webprojektes angelegt:

Hier der Inhalt der Dateien:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<?xml version="1.0" encoding="UTF-8"?>
<ivy-module version="2.0"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:noNamespaceSchemaLocation=
                   "http://ant.apache.org/ivy/schemas/ivy.xsd">
    <info module="WebApplication2" organisation="WebApplication2" revision="1.0"/>
    <configurations>
        <conf name="compile"/>
        <conf name="runtime"/>
        <conf name="compile-test"/>
        <conf name="runtime-test"/>
    </configurations>
    <dependencies>
        <dependency org="org.springframework" name="spring-webmvc" rev="3.0.0.M4" conf="" />
    </dependencies>
</ivy-module>

1
2
3
4
5
6
7
8
9
10

<?xml version="1.0" encoding="UTF-8"?>
<ivysettings>
    <settings defaultResolver="chained"/>
    <resolvers>
        <chain name="chained">
            <ibiblio name="maven2" m2compatible="true"/>
            <ibiblio name="s3.maven.springframework.org" m2compatible="true" root="http://s3.amazonaws.com/maven.springframework.org/milestone/"/>
        </chain>
    </resolvers>
</ivysettings>

Dann im Projekt Ivy aktivieren. Dazu mit der rechten Maustaste auf das Projekt und in den Ivy-Einstellungen das Häkchen machen und die zwei Dateien auswählen:

Dann noch das Projekt zwingen sich die Jars zu holen:

Und siehe da… alle Jar’s und Sourcen (wenn im Repository) sind da:

Mit der rechten Maustaste kann man nun ganz einfach die Abhängigkeiten entfernen, die man nicht braucht.

Letzte Woche war ich für einen Tag bei einem Kunden in Döbeln (Sachsen).

Thema des Workshops war ob einen nackten Swing-Client oder eine RCP-Applikation mit Netbeans bauen.  Schlussendlich haben mehr Argumente dafür gesprochen einen Swing-Client zu bauen.

Ich finde zu diesem Thema die Meinungen von Robert C. Martin gut, die er in seinem Buch Clean Code: A Handbook of Agile Software Craftmanship. Prentice Hall PTR. 2008 unter dem Kapitel 4 “Comments” vertritt.

Ein paar Auszüge:

Seite 63:

It is just plain silly to have a rule that says that every function must have a javadoc, or every variable must have a comment. Comments like this just clutter up the code, propagate lies, and lend to general confusion and disorganisation.

Seite 64f.:

And then there’s this paragon of redundancy:

/**
 * Returns the day of the month.
 *
 * @return the day of the month.
 */
 public int getDayOfMonth() {
    return dayOfMonth;
 }

Seite 71:

As useful as javadocs are for public API’s, they are anathema to code that is not intended for public consumption.

Auch wenn ich hier Auszüge aus dem Kapitel “Bad Comments” bringe, so halte ich Kommentare und Dokumentation zum Job eines Softwareentwicklers. Öffentliche Methoden müssen eine nützliche Dokumentation haben (Bitte aber nicht wie in getDayOfMonth ). Auch macht man sich oder seinen “Nachfolgern” oft das Leben wesentlich leichter seine Intention zu erklären, warum etwas genau so und nicht anders gemacht hat. Alles im Buch beschriebene möchte ich nicht hier wiedergeben. Einfach lesen.

Da aber Softwareentwicklung in den meisten Fällen im Team erfolgt, sollte man sich aber auf Regeln einigen und diese dann auch einhalten.

count: 10
static  msec: 0
get     msec: 0
new     msec: 0
count: 100
static  msec: 0
get     msec: 0
new     msec: 0
count: 1000
static  msec: 0
get     msec: 0
new     msec: 2
count: 10000
static  msec: 4
get     msec: 1
new     msec: 16
count: 100000
static  msec: 1
get     msec: 1
new     msec: 32
count: 1000000
static  msec: 0
get     msec: 0
new     msec: 224
count: 10000000
static  msec: 0
get     msec: 0
new     msec: 1848
count: 100000000
static  msec: 0
get     msec: 0
new     msec: 19029

Und hier noch das Beispiel:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

import java.util.HashMap;
import java.util.HashSet;
import java.util.Map;
import java.util.Set;
 
public class Main {
 
    private static final Person PERSON = new Person();
    private static long timestamp;
 
    public static void main(String[] args) {
        int count = 10;
        for(int i = 1; i < 9; i++){
            System.out.println("count: " + count);
            iterate(count);
            count *= 10;
        }
    }
 
    private static void iterate(int count){
        timestamp = System.currentTimeMillis();
        iterateStatic(count);
        out("static ");
        timestamp = System.currentTimeMillis();
        iterateGetter(count);
        out("get    ");
        timestamp = System.currentTimeMillis();
        iterateNew(count);
        out("new    ");
    }
 
    private static Person getPerson(){
        return PERSON;
    }
 
    private static void iterateStatic(int count){
        for(int i = 0; i < count; i++){
            Person person = PERSON;
            person.blub();
        }
    }
    private static void iterateNew(int count){
        for(int i = 0; i < count; i++){
            Person person = new Person();
            person.blub();
        }
    }
    private static void iterateGetter(int count){
        for(int i = 0; i < count; i++){
            Person person = getPerson();
            person.blub();
        }
    }
    private static void out(String s){
        System.out.println(s + " msec: " + (System.currentTimeMillis()-timestamp));
    }
}
 
class Person {
 
    private Map<?, ?> aMap = new HashMap<String, Object>();
    private Set<?> aSet = new HashSet<String>();
 
    public Person() {
    }
 
    void blub(){
    }
}