Prolafex Nr. 3: Clevere Fragestellung
Casting ist ja schlimm genug. Aber irgendwie will es nicht immer gelingen, die Klassenstruktur derart zu definieren, dass ein explizites Konvertieren unnötig ist. Leider ist es oft so, dass definitionsbedingt ein Casting zwingend notwendig ist.
- Michael Wiedeking
Pro·la·fex, das; -, -e <engl.-lat.> [Abk. für : programming language feature extra ordinem]: Element einer Programmiersprache, das aus verschiedensten Gründen besondere Beachtung verdient – ohne jedermann gefallen zu müssen.
Casting ist ja schlimm genug. Aber irgendwie will es nicht immer gelingen, die Klassenstruktur derart zu definieren, dass ein explizites Konvertieren unnötig ist. Leider ist es oft so, dass definitionsbedingt ein Casting zwingend notwendig ist.
In Java etwa definiert Object eine equals-Methode, damit jedes Objekt mit jedem anderen verglichen werden kann.
boolean equals(Object obj)
Damit sich nun Objekte einer bestimmten Art mit gleichartigen Objekten vergleichen lassen, muss also ein Cast vorgenommen werden. In einer Klasse Point mit den zwei Komponenten x und y beispielsweise könnte ein Vergleich über das komponentenweise Vergleichen implementiert werden. Ein Zugriff ist aber direkt nicht möglich, da Object (natürlich) die Eigenschaften von Point nicht kennt.
class Point {
int x;
int y;
boolean equals(Object obj) {
if (obj instanceof Point) {
Point p = (Point) obj;
return this.x == p.x && this.y == p.y;
}
return false;
}
}
Neuere Programmiersprachen, darunter Ceylon und Kotlin, benötigen das explizite Casten nicht mehr. So könnte etwa der innere Teil der obigen equals-Methode in Kotlin wie folgt aussehen:
if (obj is Point) {
return this.x == obj.x && this.y == obj.y
}
Da der Compiler weiß, dass es sich bei dem Objekt obj um ein Point handelt, lässt sich das nötige Casting implizit vornehmen. Ein "Smart Cast" funktioniert dann auch in einer verknüpften Bedingung, etwa
if (x !is String || x.length == 0) {
return
}
Damit fühlt sich der Umgang mit Objekten ein bisschen glatter und natürlicher an. Viele IDEs unterstützen das ja ohnehin schon, indem sie bei der Auswahl der möglichen Felder und Methoden auch diejenigen anbieten, die nach dem umschließenden Test auf Typzugehörigkeit möglich sind; wählt man das gewünschte Element aus, wird gegebenenfalls ein explizites Casting ergänzt.
Es ist eigentlich erstaunlich, dass eine so naheliegende Umsetzung so lange auf sich warten ließ. ()
