影视著作鉴定委员会成立 离伸张正义还有多远？
Generische Programmierung in Java wird durch sog. Generics seit Java 1.5 erm?glicht. Der Begriff steht synonym für ?parametrisierte Typen“. Die Idee dahinter ist, zus?tzliche Variablen für Typen einzuführen. Diese Typ-Variablen repr?sentieren zum Zeitpunkt der Implementierung unbekannte Typen. Erst bei der Verwendung der Klassen, Schnittstellen und Methoden werden diese Typ-Variablen durch konkrete Typen ersetzt. Damit kann typsichere Programmierung meistens gew?hrleistet werden. Jedoch nicht immer.[1]
Das Konzept
[Bearbeiten | Quelltext bearbeiten]Ab Version 5.0 (?Tiger“, 2004 ver?ffentlicht) steht auch in der Programmiersprache Java mit den Generics ein syntaktisches Mittel für die generische Programmierung zur Verfügung. Damit lassen sich Klassen und Methoden (Methoden auch unabh?ngig von ihren Klassen) mit Typen parametrisieren. Damit werden der Sprache einige ?hnliche M?glichkeiten er?ffnet, die sich vergleichbar bei den Templates in C++ bieten.
Prinzipiell gibt es aber durchaus wesentliche Unterschiede. W?hrend in Java über die Schnittstelle der Typparameter parametrisiert wird, wird in C++ direkt über den Typ des Typparameters selbst parametrisiert. Der Quelltext eines C++-Templates muss für den Anwender (d. h. beim Einsetzen des Typparameters) verfügbar sein, w?hrend ein generischer Java-Typ auch als übersetzter Bytecode ver?ffentlicht werden kann. Für verschiedene konkret verwendete Typparameter produziert der Compiler duplizierten Zielcode.
Beispielsweise bietet die Funktion std::sort in C++ die M?glichkeit, alle Container zu sortieren, die bestimmte Methoden anbieten (hier speziell begin() und end(), die jeweils einen Iterator liefern) und deren Typparameter den 'operator<' implementiert (oder explizit eine andere Vergleichsfunktion angegeben wurde). Ein Nachteil, der sich durch dieses System ergibt, ist die (für den Programmierer!) schwierigere übersetzung. Der Compiler hat keine andere M?glichkeit, als den Typparameter in jedem Fall durch den geforderten konkreten Typ zu ersetzen und den ganzen Code erneut zu kompilieren.
Sehr leicht k?nnen bei unpassenden Typparametern und anderen Problemen komplizierte und unverst?ndliche Compiler-Meldungen entstehen, was einfach mit der Tatsache zusammenh?ngt, dass die konkreten Anforderungen an die Typparameter unbekannt sind. Die Arbeit mit C++-Templates erfordert deshalb eine lückenlose Dokumentation der Anforderungen an einen Typparameter. Durch Template-Metaprogrammierung k?nnen die meisten Anforderungen (Basisklasse, Vorhandensein von Methoden, Kopierbarkeit, Zuweisbarkeit etc.) auch in speziellen Konstrukten abgefragt werden, wodurch sich lesbarere Fehlermeldungen ergeben. Obgleich sie standardkonform sind, werden diese Konstrukte jedoch nicht von allen Compilern unterstützt.
Dagegen sind den generischen Klassen und Methoden in Java die Anforderungen (engl. constraints) an ihre eigenen Typparameter bekannt. Um eine Collection (ohne Comparator) zu sortieren, müssen die enthaltenen Elemente vom Typ Comparable sein, also dieses Interface implementiert haben. Der Compiler muss lediglich prüfen, ob der Typparameter ein Untertyp von Comparable ist, und kann damit schon sicherstellen, dass der Code korrekt ist (d. h. die erforderliche Methode compareTo verfügbar ist). Weiterhin wird ein und derselbe Code für alle konkreten Typen verwendet und nicht jedes Mal dupliziert.
Praktische Beispiele
[Bearbeiten | Quelltext bearbeiten]Ein Programm verwendet eine ArrayList, um eine Liste von JButtons zu speichern.
Bisher war die ArrayList auf den Typ Object fixiert:
List list = new ArrayList();
list.add(new JButton("Button 1"));
list.add(new JButton("Button 2"));
list.add(new JButton("Button 3"));
list.add(new JButton("Button 4"));
list.add(new JButton("Button 5"));
for (int i = 0; i < list.size(); i++) {
JButton button = (JButton) list.get(i);
button.setBackground(Color.white);
}
Man beachte die notwendige explizite Typumwandlung (auch ?Cast“ genannt) sowie die Typunsicherheit, die damit verbunden ist. Man k?nnte versehentlich ein Objekt in der ArrayList speichern, das keine Instanz der Klasse JButton ist. Die Information über den genauen Typ geht beim Einfügen in die Liste verloren, der Compiler kann also nicht verhindern, dass zur Laufzeit bei der expliziten Typumwandlung von JButton eine ClassCastException auftritt.
Mit generischen Typen ist in Java Folgendes m?glich:
List<JButton> list = new ArrayList<JButton>();
list.add(new JButton("Button 1"));
list.add(new JButton("Button 2"));
list.add(new JButton("Button 3"));
list.add(new JButton("Button 4"));
list.add(new JButton("Button 5"));
for (int i = 0; i < list.size(); i++)
list.get(i).setBackground(Color.white);
Beim Auslesen ist nun keine explizite Typumwandlung mehr notwendig, beim Speichern ist es nur noch m?glich, JButtons in der ArrayList list abzulegen.
Ab Java7 ist die Instanzierung generischer Typen vereinfacht worden. Die erste Zeile in obigem Beispiel kann seit Java 7 folgenderma?en geschrieben werden:
List<JButton> list = new ArrayList<>();
Die beiden leeren spitzen Klammern werden aufgrund ihrer Form auch als Diamant-Operator (englisch Diamond-Operator) bezeichnet.[2][3]
Durch Kombination von generischen Typen mit den erweiterten For-Schleifen l?sst sich obiges Beispiel kürzer fassen:
List<JButton> list = new ArrayList<>();
list.add(new JButton("Button 1"));
list.add(new JButton("Button 2"));
list.add(new JButton("Button 3"));
list.add(new JButton("Button 4"));
list.add(new JButton("Button 5"));
for (JButton b: list)
b.setBackground(Color.white);
Ein Beispiel für eine generische Klasse, die zwei Objekte von beliebigem, aber einander gleichem Typ beinhaltet, liefert der folgende Beispielcode:
public class DoubleObject<T> {
private T object1;
private T object2;
public DoubleObject(T object1, T object2) {
this.object1 = object1;
this.object2 = object2;
}
public String toString() {
return this.object1 + ", " + this.object2;
}
public static void main(String[] args) {
DoubleObject<String> s = new DoubleObject<>("abc", "def");
DoubleObject<Integer> i = new DoubleObject<>(123, 456);
System.out.println("DoubleObject<String> s=" + s.toString());
System.out.println("DoubleObject<Integer> i=" + i.toString());
}
}
Varianzf?lle
[Bearbeiten | Quelltext bearbeiten]In Java k?nnen die nachfolgenden Varianzf?lle unterschieden werden. Sie bieten jeweils eine v?llig eigenst?ndige Flexibilit?t beim Umgang mit generischen Typen und sind jeweils absolut statisch typsicher.
Invarianz
[Bearbeiten | Quelltext bearbeiten]Bei Invarianz ist der Typparameter eindeutig. Damit bietet Invarianz die gr??tm?gliche Freiheit bei der Benutzung des Typparameters. Beispielsweise sind für die Elemente einer ArrayList<Integer> alle Aktionen erlaubt, die auch bei der direkten Benutzung eines einzelnen Integers erlaubt sind (inklusive Autoboxing). Beispiel:
List<Integer> list = new ArrayList<Integer>();
// ...
Integer x = list.get(index);
list.get(index).methodeVonInteger();
list.set(index, 98347); // Autoboxing, entspricht Integer.valueOf(98347)
int y = list.get(index); // Auto-Unboxing
Diese M?glichkeiten werden mit wenig Flexibilit?t bei der Zuweisung von Objekten der generischen Klasse selbst erkauft. Beispielsweise ist Folgendes nicht erlaubt:
List<Number> list = new ArrayList<Integer>();
und das, obwohl Integer von Number abgeleitet ist. Der Grund liegt darin, dass der Compiler hier nicht mehr sicherstellen kann, dass keine Typfehler auftreten. Mit Arrays, die eine solche Zuweisung erlauben, hat man schlechte Erfahrungen gemacht:
// OK, Integer[] ist abgeleitet von Number[]
Number[] array = new Integer[10];
// ArrayStoreException zur Laufzeit: Double -> Integer sind nicht
// zuweisungskompatibel
array[0] = new Double(5.0);
Kovarianz
[Bearbeiten | Quelltext bearbeiten]Man bezeichnet Arrays als kovariant, was besagt:
oder allgemeiner:
Es verh?lt sich also der Array-Typ bzgl. der Vererbungshierarchie genauso wie der Typparameter. Kovarianz ist auch mit generischen Typen m?glich, allerdings nur mit Einschr?nkungen, so dass Typfehler zur Kompilierzeit ausgeschlossen werden k?nnen.
Referenzen müssen mit der Syntax ? extends T explizit als kovariant gekennzeichnet werden. T hei?t upper typebound, also der allgemeinste Typparameter, der erlaubt ist.
List<? extends Number> list;
list = new ArrayList<Double>();
list = new ArrayList<Long>();
list = new ArrayList<Integer>();
// Typfehler vom Compiler
list.set(index, myInteger);
// OK aber Warnung vom Compiler: unchecked cast
((List<Integer>) list).set(index, myInteger);
Das Ablegen von Elementen in diesen Listen ist nicht m?glich, da dies, wie oben beschrieben, nicht typsicher ist (Ausnahme: null kann abgelegt werden). Bereits zur Kompilierzeit tritt ein Fehler auf. Allgemeiner gesagt, ist die Zuweisung
nicht erlaubt.
M?glich dagegen ist das Auslesen von Elementen:
Number n = list.get(index); // OK
Integer i = list.get(index); // Typfehler: Es muss sich bei '? extends Number'
// nicht um ein Integer handeln.
Integer j = (Integer) list.get(index); // OK
Die Zuweisung
ist also erlaubt, nicht aber die Zuweisung
Generics bieten also wie Arrays kovariantes Verhalten, verbieten aber alle Operationen, die typunsicher sind.
Kontravarianz
[Bearbeiten | Quelltext bearbeiten]Kontravarianz bezeichnet das Verhalten der Vererbungshierarchie des generischen Typs entgegen der Hierarchie seines Typparameters. übertragen auf das obige Beispiel würde das bedeuten: Eine Liste<Number> w?re zuweisungskompatibel zu einer Liste<Double>. Dies wird folgenderma?en bewerkstelligt:
List<? super Double> list;
list = new ArrayList<Number>();
list = new ArrayList<Double>();
list = new ArrayList<Object>();
Ein Objekt, das sich kontravariant verh?lt, darf keine Annahmen darüber machen, inwiefern ein Element vom Typ V von T abgeleitet ist, wobei T der lower Typebound ist (im Beispiel von ? super Double ist T Double).
Deshalb kann aus den obigen Listen nicht gelesen werden:
// Fehler: 'list' k?nnte vom Typ List<Object> sein
Number x = list.get(index);
// Fehler: 'list' k?nnte List<Object> oder List<Number> sein
Double x = list.get(index);
// Die einzige Ausnahme: Objects sind auf jeden Fall in der Liste
Object x = list.get(index);
Nicht erlaubt, da nicht typsicher, ist also die Zuweisung ? super T → (abgeleitet von Object)
Unschwer zu erraten: Im Gegenzug kann in eine solche Liste ein Element abgelegt werden:
List<? super Number> list;
list.add(new Double(3.0)); // OK: 'list' hat immer den Typ List<Number>
// oder List<Basisklasse von Number>. Damit
// ist die Zuweisung Double -> T immer erlaubt.
Uneingeschr?nkte parametrische Polymorphie
[Bearbeiten | Quelltext bearbeiten]Zu guter Letzt bieten Generics noch g?nzlich polymorphes Verhalten an. Hierbei kann keinerlei Aussage über die Typparameter gemacht werden, denn es wird in beide Richtungen keine Grenze angegeben. Dafür wurde die Wildcard definiert. Sie wird durch ein Fragezeichen repr?sentiert.
List<?> list;
list = new ArrayList<Integer>();
list = new ArrayList<Object>();
list = new ArrayList<String>();
// ...
Der Typparameter selbst kann hierbei nicht genutzt werden, da keine Aussage m?glich ist. Lediglich die Zuweisung T → Object ist erlaubt, da T auf jeden Fall ein Object ist. Im Gegenzug ist garantiert, dass der Code mit allen Ts arbeiten kann.
Nützlich kann so etwas sein, wenn man nur mit dem generischen Typ arbeitet:
// Keine Informationen über den Typparameter n?tig, kann ''beliebige'' Listen
// aufnehmen.
int readSize(List<?> list) {
return list.size();
}
Zur Verdeutlichung, dass hier Wildcards unn?tig sind, und es eigentlich gar nicht um irgendeine Varianz geht, sei folgende Implementierung der obigen Funktion angegeben:
<T> int readSize(List<T> list) {
return list.size();
}
Weblinks
[Bearbeiten | Quelltext bearbeiten]- Ina Brenner: Tutorial zu Generics in Java von der Autorin eines Buchs zur Java-Zertifizierung SCJP (deutsch)
- Klaus Kreft, Angelika Langer: Artikelserie zu Generics in Java im JavaSpektrum (deutsch)
- Christian Ullenboom: Kapitel zu Generischen Datentypen aus dem Galileo-Openbook Java ist auch eine Insel (deutsch)
Einzelnachweise
[Bearbeiten | Quelltext bearbeiten]- ↑ Nada Amin, Ross Tate: Java and Scala’s Type Systems are Unsound: The Existential Crisis of Null Pointers. In: ACM (Hrsg.): OOPSLA 2016. New York 2016, ISBN 978-1-4503-4444-9, S. 838–848 (englisch, githubusercontent.com [PDF; 215 kB; abgerufen am 31. M?rz 2017]).
- ↑ Joachim Goll, Cornelia Heinisch: Java als erste Programmiersprache: Grundkurs für Hochschulen. 8. Auflage. Springer, Wiesbaden 2016, ISBN 978-3-658-12117-4, S. 725.
- ↑ Reinhard Schiedermeier: Programmieren mit Java. 2. Auflage. Pearson Studium, München 2010, ISBN 978-3-86894-031-2, S. 375.