Generizität in Java und C# Riad Djemili ([email protected]) Seminar Objektorientierte...
-
Upload
gotthilf-rasmusson -
Category
Documents
-
view
109 -
download
4
Transcript of Generizität in Java und C# Riad Djemili ([email protected]) Seminar Objektorientierte...
Generizitätin Java und C#
Riad Djemili ([email protected])
Seminar Objektorientierte Programmiersprachen
Prof. Dr.-Ing. Klaus-Peter Löhr
FU-Berlin WS 03/04
Übersicht
1. Motivation1. Polymorphie
2. Probleme
2. Generizität1. Grundlagen (Eiffel, C++)
2. Java
3. C#
Motivation
Polymorphie
PolymorphieEigenschaft von Variablen, Objekte unterschiedlichen Typs speichern zu können. Variablen können Objekte zugewiesen werden, die vom gleichen Typen wie diese Variable oder von einem abgeleiteten Typen sind.
List list = new LinkedList();
Statischer TypIn der Variablendeklaration festgelegter Datentyp.
Dynamischer TypBeim Erzeugen des Objekts festgelegter Typ.
Probleme
Mächtiges Paradigma, aber nicht perfekt! Statischer Datentyp ist fest und kann für eigene
Anwendungen nicht leicht angepasst werden. Klassische Lösung:
Nutzung des niedrigsten gemeinsamen Typen der Klassenhiarchie.
Spezialiserte Implementationen mit unterschiedlichen Typen.
Ansatz 1:Nutzung von Vaterobjekten
Beispiel Java: Liste
class MyList { boolean add(Object o) {..} Object get(int index) {..}}
..
//associates Integer-Objects
MyList ints = new MyList();
ints.add(new Integer(4));
Integer foo = (String)ints.get(0);
• Unsichere Konvention, statt expliziter Sprachunterstützung.
• Typwandlungs-Laufzeitfehler, statt Übersetzungsfehler.
• Teure Typwandlungen zu Basisklasse und zurück.
• Nicht alle Programmiersprachen kennen gemeinsame Vaterobjekte.
Ansatz 2:Spezialisierte Implementationen
Beispiel Java: Math-Methoden
public static double abs(double a) {..}public static float abs(float a) {..} public static int abs(int a) {..}public static long abs(long a) {..}
Methodenüberladen (gleiche Methodennamen mit unterschiedlichen Signaturen), um verschiedene Datentypen zu unterstützen. Effizient, aber aufgeblähter und unübersichtlicher Code!
Lösung: Generizität (I)
Möglichkeit nicht nur dynamischen Typ, sondern auch statischen Typ zu variieren.
Universelle Polymorphie
Polymorphie
Inklusions-Polymorphie
(überschreiben)
Ad hoc – Polymorphie(überladen)
Parametrische Polymorphie(Generizität)
Lösung: Generizität (II)
ZieleHöhere Typsicherheit, durch Vermeidung von
unsicheren Typumwandlungs-Laufzeitfehlern.Wiederverwendbarer Code.Bessere Lesbarkeit, durch expliziter Syntax,
statt impliziter Konvention.Effizienz, da keine unnötigen Typwandlungen.
Klassische Generizitätin Eiffel und C++
Klassen Generizität
class STACK [T] ..feature
push ( elem: T ) isdo .. end
top: T isdo .. end
end
Anwendung:
intstack : STACK[INTEGER];intstack.push(3);
•Klassen werden mit formalen Typparametern deklariert.•Tatsächliche Datentypen werden als Parameter übergeben.
Ungenerischer Stack in Eiffel Generischer Stack in Eiffel
class STACK ..feature
push ( elem: INTEGER ) isdo .. end
top: INTEGER isdo .. end
end
Anwendung:
intstack : STACK;intstack.push(3);
Mehrere Parametertypen
Ausserdem mehrere generische Parametertypen möglich.
Beispiel: Ein generisches Paar in Eiffel
class PAIR[T, U] feature {NONE} // private first : T; second : U; end
Anwendung:
birthdate : PAIR[STRING,DATE];
Methoden Generizität
Generische Typen existieren auch für Funktionen!
Beispiel: Vertausche-Operation in C++
template<class T> void swap(T& x, T& y) { T temp = x; x = y; y = temp; }
Anwendung
int i,j; swap<int> (i,j); //a swap for int char i,j; swap<char>(i,j); //a swap for char
Methoden Generizität (II)
Im Gegensatz zu generischen Klassen können Typparameter bei Methoden implizit aus Argumenten abgeleitet werden!
Beispiel in C++:
int i,j; swap(i,j); // a swap for int float i,j; swap(i,j); // a swap for float
Ohne explizite Datentypangabe.
Eingeschränkte Generizität
Typeinschränkungen mittels klassischer Polymorphie:
bool pos(Comparable foo) {return foo.compareTo(x);}
Problem: Wie können wir ähnlich sichere Annahmen für generische Typen machen?
Lösung: Constrained Genericty.
class SORTED_LIST [T->COMPARABLE] ..
end
Erzwingt in Eiffel, dass T Unterklasse von Comparable sein muss, ansonsten Übersetzungsfehler.
Java
Übersicht
Seit 1995 von Sun Microsystems entwickelt. Stark objektorientiert. Umfangreiche Klassenbibliothek. Automatische Speicherverwaltung. Plattformunabhängig. Aus „Generic Java“ entwickelt und offiziell ab Java
1.5 (Sommer 2004, Codename: Tiger) unterstützt.
Ziele der Java-Implementation
Vollständige Ersetzung der aktuellen Java API durch generische Version.„Retrofitting“ alten Codes.
Vollständige Rückwärtskompabilität.Alter Code soll ohne Änderung ausführbar
bleiben.
Parametertypen
Erlaubte Typarten: Klassen sind als Parametertypen erlaubt. Primitive Typen sind nicht erlaubt. Unteranderem da für sie kein
einheitliches Typsystem existiert.
Sie müssen jeweils (uneffizient) in ihre Wrapper-Klassen gekapselt werden.
z.B. int → Integer, boolean → Boolean
Übrigens automatisches „Casting“ (Autoboxing) auch ab Java 1.5.
Ausserdem mehrere Typparameter erlaubt.
Klassen Generizität
Beispiel: Die neue java.util.Stack Klasse
class Stack<E> extends Vector<E> { public E push(E item) {..} public synchronized E pop() {..} public synchronized E peek() {..} public boolean empty() {..} public synchronized int search(Object o) {..}}
Anwendung:
Stack<String> foo = new Stack<String>();
Methoden Generizität
Methoden-Generics unterstützt. Typangabe (unintuitiverweise) vor Methodenname! Begründung ist
leichteres Parsing.
Beispiel: Eine vertausche-Operation
static <Elem> void swap(Elem[] array, int x, int y) { Elem temp = array[x]; array[x] = array[y]; array[y] = temp;}
Aufrufe auch mit impliziter Typangabe.
swap(ints, 1, 3)sort(strings)
<Integer>swap(ints, 1, 3)<String>sort(strings)
Bounds
Einschränkung (bounding) der Typen durch maximal eine Oberklasse und/oder beliebiger Anzahl von Interfaces.
Beispiel: Sortierte Liste
class SortedList<T
extends Entry implements Comparable> {..}
Übersetzung (I)
Java
Übersetzung(Bytecode)
Ausführung(JVM)
Linux Windows .. Mobile
Plattformen
Implementierung von Generizitäts-Erweiterungen auf Ebene der Übersetzung.
Übersetzung (II)
Oberster Grundsatz:Die Java Virtual Machine wird nicht verändert!
Homogener Vorgang (für jeden generischen Typen wird einmalig neuer Code generiert)
1. Generische Datentypen werden durch untere Grenze ersetzt (Erasures).
2. Casting geschieht bei Attributzugriffen und Methodenrückgaben.
3. Einsetzung von Bückenmethoden bei kovarianter Vererbung. (siehe später)
Vorgang fast analog zum „manuellen“ Vorgang bisher.
Übersetzung (III)
class Cell<A> { A value; A getValue();}
..
String f(Cell<String> cell){ return cell.value;}
class Cell { Object value; Object getValue();}
..
String f(Cell cell){ return (String)cell.value;}
Übersetzung in JVM – konformen Code.
Klasse Cell wird nur einmal generiert und kann für alle Parametertypen wiederverwendet werden.
Legacy-Code (I)
Java API soll mit generischen Typen aktualisiert werden.
Stack s = new Stack();
geht aber immernoch (sogenannte „Raw Classes“)! Ohne Angabe eines Typparameters wird implizit niedrigste Typschranke angenommen. Hier also:
Stack<Object> s = new Stack<Object>();
Ermöglicht „Rückwärts-Kompabilität“, dh. alter Code kann ohne Änderung weiter mit „retrofitted“ API Klassen arbeiten.
Evtl. auch „Vorwärts-Kompabilität“ denkbar.
Legacy-Code (II)
Zuweisungen Erlaubt
Stack s = new Stack<Integer>();
Übersetzer-Warnungen, bei Methodenaufrufem mit veränderten Argumenttypen. Attributzugriffe mit veränderten Typen.
s.push(new Integer(5)); //compile-warning
Erlaubt, aber „deprecation“-Warnung, da unsicher.
Stack<Integer> s = new Stack();
Kovarianz (I)
Bisher: Invariante Rückgabetypen Rückgabetyp einer Methode muss identisch sein mit der
überschriebenen Methode.
Jetzt: Kovariante Rückgabetypen Rückgabetyp einer Methode muss Untertyp sein für alle
Methoden, die sie überschreibt.
Kovarianz wird durch Brückenmethoden realisiert.
Kovarianz (II)class A<T> {
T something() { .. }}
class B<T implements Comparable> extends A<T> {T something() { .. }
}
class A {Object something() { .. }
}
class B extends A {Comparable something() { .. }
Object something/*2*/() { return something() }
}
JVM unterstützt intern auch Methoden mit Signaturen, die sich nur im Rückgabetypen unterscheiden.
Vererbung (I)
Unintuitive TypbeziehungLinkedList<String> ist Untertyp von
List<String>.List<String> ist aber nicht Untertyp von
List<Object>.
Vererbung (II)
Naive generische Implementation von Interface Collection:
interface Collection<E> {boolean addAll(Collection<E> c);boolean containsAll(Collection<E> c);
}
Nachteil: Aufgrund von fehlerender Typbeziehung kann die generische
Methode nur eigenen Typen aufnehmen.
Collection<Number> = new Collection<Number> col;Collection<Integer> = new Collection<Integer> ints;
col.addAll(ints); Typfehler!
Vererbung (III)
Bessere generische Implementation erlaubt kovariante Argumente:
interface Collection<E> { <T extends E> boolean addAll(Collection<T> c);
<T> boolean containsAll(Collection<T> c); }
Auch wenn aktueller Typparameter bei Methodenaufruf implizit übergeben werden kann:
Unleserliche und umständliche Notation für häufiges Programmierziel.
Vererbung (IV)
Vorangetrieben durch „Variant Generic Java” WildCard-Syntax.1. Ermöglicht bessere Lesbarkeit durch anonyme Typparameter.
interface Collection<E> {boolean addAll(Collection<? extends E> c);boolean containsAll(Collection<?> c);
}
2. Ermöglicht auch Kontravarianz.
interface Collection<E> {boolean addAll(Collection<? super E> c);boolean containsAll(Collection<?> c);
}
Aber, was trotzdem nicht geht:
List<? extends Number> = new List<Integer>;
Exceptions
Nicht vollständig unterstützt.Generics dürfen nicht von java.lang.Throwable ableiten.
Typvariablen sind erlaubt in throws – Anweisung. nicht erlaubt in catch – Anweisung.
Instanziieren von Parametertypen
Aufgrund von Erasures ist es nicht möglich Parametertypen zu instanziieren.
class Singleton<T> {private T instance;
public T getInstance() {if (instance == null)
instance = new T();
return instance;}
}
Nicht erlaubt!
Reflection
Generische Klassen als Typen bekannt, allerdings keine Kenntnis über aktuelle Typparameter zur Laufzeit, da diese beim Übersetzen entfernt werden (erasures).
class SortedSet<T extends Comparable<T>> { public SortedSet() { if (T.class == Date.class) {
.. } else if (T.class == Integer.class) {
.. } }}
Kann nicht funktionieren, da T.class hier immer vom Typ Comparable ist.
Schwächen von Erasures
Unerwartete Fehler aufgrund von gleichen Erasures class Tool {
public void do(Collection<Integer>) {..} public void do(Collection<String>) {..}}
class C<A> { A id(A x) {..}}
interface I<A> { A id(A x);}
class D extends C<String> implements I<Integer> { String id(String x) {..} Integer id(Integer x) {..}}
Zusammenfassung
Vorteil Leichter Übergang zwischen generischem und ungenerischem
Code. Keine neue konkurrierende Java API. Anonyme Typparameter (Wildcards).
Nachteil Keine primitiven Datentypen erlaubt. Uneffizient, da up/down - casting intern immernoch nötig. Kein Wissen über aktuelle generische Typparameter. Typparameter können nicht instanziiert werden. Verschiedene Restriktionen im Zusammenhang mit Erasures
C#
Übersicht
Seit Februar 2001 von Microsoft entwickelt.Stark objektorientiert.Umfangreiche Klassenbibliothek.Automatische Speicherverwaltung.Teil des .NET FrameworksBald (Mitte/Ende 2004!?) auch Generics.
Ziel der .Net Implementation
Saubere vollständige Implementation von Generics. Einführung neuer Intermediate Language Typen.
Einführung neuer generischer Klassen in das .NET Framework. Aktuelles nicht-generisches .NET Framework bleibt
erhalten.
Parametertypen
Typarten:Klassen sind als Parametertypen erlaubt.Primitive Typen sind erlaubt, da alle Typen
(Referenz- und Datentypen) einen gemeinsamen Obertypen haben.
Auch mehrere generische Typen erlaubt.
Klassen Generizität
Beispiel: Eine sortierte Liste
class SortedList<EntryType> where EntryType : IComparable{
public void insert(EntryType item) {..} public void remove(EntryType item) {..} public bool contains(EntryType item) {..} public bool empty() {..}}
Anwendung:
SortedList<int> ss = new SortedList<int>();
Ausserdem Unterstützung für Structs und Delegates.
Methoden Generizität
Methoden-Generics unterstützt. Typangabe intuitiverweise hinter Methodenname!
Beispiel: swap
static void swap<Elem>(Elem[] array, int x, int y) { Elem temp = array[x]; array[x] = array[y]; array[y] = temp; }
Aufrufe auch mit impliziter Typangabe.
swap(ints, 1, 3)sort(strings)
swap<int>(ints, 1, 3)sort<string>(strings)
Constraining
Einschränkung (analog zu Java) der Typen durch maximal eine Oberklasse und/oder beliebiger Anzahl von Interfaces.
Beispiel: Zwei eingeschränkte Typparameter.
pulic class MyList<K,T> where K : Icomparable<K>, IEnumerable
where T : Customer { .. }
Notation umständlicher als bei Java!?
Übersetzung (I)
C#
Übersetzung(MIL)
Ausführung(CLR)
(Linux) Windows .. Mobile
Plattformen
Implementierung von Generizitäts-Erweiterungen auf Ebene der Ausführung.
Java#VB .NET ..
Sprachen
Übersetzung (II)
Typabhängige Übersetzung:Für ReferenceTypes (Klassen)
wird einmal generierter gemeinsamer Code wiederverwendet (homogener Vorgang).
Für ValueTypes (primitive Typen)wird bei jeder ersten Benutzung spezieller Code generiert (heterogener Vorgang).
Legacy-Code (I)
.NET API erhält zusätzliche generische Klassen. Ausmass abgesehen von Collections Namespace
noch unbekannt.
„Rückwärts-Kompabilität“ wird durch Beibehaltung der alten Klassen gewährleistet.
Mischung von generischem und ungenerischem Code nur schwer.
Legacy-Code (II)
System.Collections System.Collections.GenericsComparer Comparer<T>
HashTable Dictionary<K,T>
ArrayList List<T>
Queue Queue<T>
SortedList SortedDictionary<K,T>
Stack Stack<T>
ICollection ICollection<T>
System.Comparable IComparable<T>
IComparer IComparer<T>
Idictionary IDictionary<K,T>
Ienumerable IEnumerable<T>
IEnumerator IEnumerator<T>
IKeyComparer IKeyComparer<T>
IList IList<T>
Typenvarianz
Nur Invariante RückgabetypenRückgabetyp einer Methode muss identisch
sein mit der überschriebenen Methode.
Keine Wildcard-Syntax.Keine Kontravarianz.
Exceptions
Vollständige Unterstützung.Generics dürfen von System.Exception
ableiten.Typvariablen sind
erlaubt in throws – Anweisung. erlaubt in catch – Anweisung, wenn sie vom Typ System.Exception ableiten.
Instanziieren von Parametertypen
Parametertypen können instanziiert werden, wenn sie einen Konstruktor ohne Argumente bieten. Garantie muss als zusätzliches Constraint „new()“ angegeben werden.
Beispiel:
class Singleton<T> where T : new() { private T instance;
public T getInstance() {if (instance == null) instance = new T();
return instance; }}
Reflection
Volle Reflectionunterstützung von generischen Typen.
Type type = typeof(List<int>);
Type-Klasse wird erweitert mit speziellen Eigenschaften von generischen Typen:
int GenericParameterPosition{virtual get;} bool HasGenericParameters{get;} bool HasUnboundGenericParameters{virtual get;} bool IsGenericParameter{virtual get;} bool IsGenericTypeDefinition{virtual get;} virtual Type BindGenericParameters(Type[] typeArgs); virtual Type[] GetGenericParameters(); virtual Type GetGenericTypeDefinition();
Erlaubt auch Zugriff auf aktuelle Typparameter.
Zusammenfassung
Vorteil Intuitive und vollständige Umsetzung von generischen Typen. Effizienz. Vollständige Typkenntnis zur Laufzeit (Reflection).
Nachteil Absolute Trennung zwischen generischen und nicht
generischem Code. API kann nicht rückwärtskompatibel umgeschrieben werden. Keine Kontravarianz. Umständlichere Notation.
Konklusion
Fazit
Generizität Sinnvoll und allgemein anerkannt. Birgt aber auch zusätzliche Komplexität. Nicht immer
klar, wann angebracht. Implementationen
Java Rückwärts-Kompabilität positiv, allerdings grosse
Einschränkungen bei Nutzung von generischen Typen. C#
Gute Unterstützung für generische Typen, aber unklare Konsequenz für .NET Framework.
Referenzen
Adding Generics to the Java Programming Language: Public Draft Specification, Version 2.0Bracha, Cohen, Kemper, Odersky, Stoutamire, Thorup, Wadler
Variant Generic Types Sun Microsystems
Design an Implementation of Generics forthe .NET Common Language RuntimeAndrew Kennedy, Don Syme
MSDN Article: Introduction to C# GenericsJuval Lowy