Primitive Obsession

Ich habe das Brutal Refactoring Game bereits bei der Java User Group Erlangen Nürnberg kennen gelernt. Zuletzt wurde eine Runde dieses Spiels bei der Softwerkskammer Nürnberg durchgeführt. Was diese spezielle Form eines Code Retreat auszeichnet, habe ich bereits beschrieben.

Auch bei der Softwerkskammer haben wir das Retreat mit dem bekannten Tic Tac Toe Kata durchgeführt. Von den 17 Regeln des Brutal Refactoring Games hat uns besonders die Regel „Primitive Obsession“ behindert oder besser gesagt gefordert.

Was ist Primitive Obsession?

Die Regel besagt, dass mein die Verwendung von Primitiven Typen wie z.B. boolean, byte, int, long, float oder double in Java vermeidet. Statt eines Primitives ist eine eigenen Klasse (keine Wrapper-Klasse wie z.B. Integer oder Long) zu verwenden. Wenn man die Regel ganz genau nimmt, ist auch die Verwendung eines Enums nicht gestattet, weil dieses im Endeffekt nur ein “verstecktes” int ist.

Bei der Entwicklung von Tic Tac Toe hat man z.B. sehr schnell die einzelnen Spieler als Integer oder als Enum modelliert. Die Regel Primitive Obsession zwingt hier zur Implementierung von eigenen Klassen. Wir haben den beiden Klassen PlayerNone und PlayerOne zusätzlich noch die Basisklasse Player spendiert.

public class Player {

    @Override
    public boolean equals(Object other) {
        if (other == null) {
            return false;
        }
        return other.getClass().equals(this.getClass());
    }

}


public class PlayerNone extends Player {

}

public class PlayerOne extends Player {

}

Primitive Obsession in der Praxis

In der täglichen Praxis wird niemand die Regel 1:1 anwenden. Viel zu schnell hat man eine zu große Anzahl an Klassen. Den Gedanken, der hinter dieser Regel steckt, werde ich in Zukunft aber sicherlich öfter anwenden.

Es ist in objektorientierten Sprachen nicht notwendig, jede Entität mit einem Integer abzubilden. Unweigerlich hat man mit der Verwendung von Primitives auch Konstanten mit “magic values”. Der Code wird dadurch nicht lesbarer und auch die Wartung wird umfangreicher.

Was ich bei der Vermeidung von Primitives interessant finde ist, dass ich mir die Prüfung auf gültige Werte für den Primitive spare. Verwende ich für die Modellierung des Spielers ein int, muss ich immer prüfen, ob nicht ein ungültiger Wert gesetzt ist. Bei der Verwendung einer Klasse oder eines Enums kann das nicht passieren bzw. der Compiler sorgt dafür, dass dies nicht passieren kann. Der Code wird dadurch lesbarer und frei von den üblichen Prüfungen.