Eine Regel der Softwareentwicklung, die ich verinnerlicht habe: Wenn Entwickler die Möglichkeit haben etwas zu tun, dann tun sie es auch. Deswegen müssen Systeme so weit wie möglich restriktiv ausgelegt sein. Den richtigen Restriktionsgrad zu treffen ist allerdings kniffelig.
In der Wikipedia wird die boolsche Variable wie folgt beschrieben:
Boolesche Variable, benannt nach George Boole, sind Elemente einer booleschen Algebra, die immer einen von zwei Werten annehmen.
Diese – allgemeingültige Definition – hält findige Entwickler natürlich nicht davon ab, einer boolschen Variable drei mögliche Werte zu geben. Möglicht macht dies eine Eigenart des Java Typensystems. Für jeden primitiven Datentyp existiert ein Äquivalent als Klasse. So auch für den primitiven Datentyp boolean die Klasse java.lang.Boolean. Variablen die auf eine Boolean-Klasse verweisen können null sein – also nicht initialisiert. Die Boolean-Variable kann anstatt zwei Werten (true und false eines Boolean-Exemplars) drei Werte haben: ja, nein, weissnicht (die null-Referenz).
APIs, die mit derartigen Zuständen arbeiten können nur als schlampig designt bezeichnet werden. In der JBoss RichFaces Bibliothek wird genau so ein API-Design verwendet. Die Methoden-Signaturen des Interfaces org.richfaces.component.state.TreeStateAdvisor liefern Booleans mit drei dokumentieren (immerhin) Zuständen zurück. Ein sauberes API-Design hätte hier Konstanten definiert, um die Zustände zu beschreiben und nicht einen solchen Murks.
Im TreeStateAdvisor nicht, vielleicht aber der Implementierung des Notfallpatents :-)
