Erbangelegenheiten … und "comprises"

Babel-Bulletin  –  19 Kommentare

Stellt man in der Objektorientierung eine Klasse zur Verfügung, so kann in der Regel jeder, der möchte, davon ableiten. Das lässt sich meist nur dadurch verhindern, dass man die Klasse bezüglich der Ableitung verschließt. In C# macht man das etwa durch Markieren der Klasse mit sealed, in Java mit final.

Ist eine Klasse nicht verschlossen, so öffnet man jedermann Tor und Tür. Das ist aber nicht immer gewünscht, und so müsste man die Klasse verstecken. Dann könnte diese aber auch außerhalb von keinem mehr benutzt werden, was aber insbesondere bei Basisklassen nicht immer gewünscht ist.

Die einzig verbleibende Möglichkeit wäre dann nur noch ein Kommentar, der beschreibt, was erlaubt ist und was nicht. Aber von Kommentaren weiß man ja, dass sie entweder ignoriert oder – wenn gelesen – einfach nicht beachtet und beherzigt werden. Also bedarf es eines Mechanismus, mit dem man präziser beschreiben kann, wie man sich eine Klassenhierarchie vorstellt.

Beispielsweise ist in Java jedes Objekt, das im Zusammenhang mit der Ausnahmebehandlung geworfen werden kann, ein Throwable. Davon abgeleitet sind die Klassen Error und Exception. Allerdings hindert einen nichts daran, selbst von Throwable abzuleiten. Kann man machen, ist aber nicht schön, weil man dann mit etwas zu tun haben könnte, dessen Semantik im Gegensatz zu Error und Exception nicht klar ist.

Und hier kommt das Schlüsselwort comprises ins Spiel. Leo sagt, dass to comprise sth. etwa umfassen oder beinhalten heißt. Unter comprises findet sich sogar sth. comprises of, das mit etw. wird aus … gebildet übersetzt wird. In meiner Programmiersprache wird man deshalb (in Anlehnung an die Programmiersprache Fortress) mit

class Throwable comprises {Error, Exception}

ausdrücken können, dass die Klasse Throwable exakt zwei ableitende Klassen hat, nämlich Error und Exception. Damit kann der oben beschriebene Fall ausgeschlossen werden und die Anwender müssen sich damit für eine der beiden Varianten entscheiden.

In Skala wird das Problem übrigens dadurch gelöst, dass eine Klasse nach außen hin durchaus abstrakt und abgeschlossen sein kann, innerhalb des Namensraums aber trotzdem noch überschrieben werden darf. Mir gefällt die comprises-Version aber deswegen besser, weil es nun der Klasse sofort anzusehen ist, dass sie ausschließlich die Basis für die angegebenen Klassen ist, ohne dass es eines weiteren Kommentars bedarf.

Um an die Fragen der letzten Einträge anzuknüpfen, sei an dieser Stelle noch folgendes erwähnt: Wenn man weiß, was comprises heißt, könnte es einem beim Verstehen dieser Konstruktion helfen. Aber die Spitzfindigkeiten – die ich beizeiten vorstellen werde – muss man dann doch nachlesen. Also ist es eigentlich auch egal, ob man das Wort nun versteht oder nicht. Und irgendwie gewöhnt man sich ja dann doch an alles, oder?