generics2: improve material, add further remarks

Author: cagix

lecture/java-classic/generics2-bounds-wildcards.md

@@ -4,18 +4,19 @@ title: "Generics2: Bounds & Wildcards"
 ---
 
 ::: tldr
-Typ-Variablen können weiter eingeschränkt werden, in dem man einen verpflichtenden
-Ober- oder Untertyp angibt mit `extends` bzw. `super`. Damit muss der später bei der
-Instantiierung verwendete Typ-Parameter entweder die Oberklasse selbst sein oder
-davon ableiten (bei `extends`) bzw. der Typ-Parameter muss eine Oberklasse der
-angegebenen Schranke sein (`super`).
-
-Durch die Einschränkung mit `extends` können in der Klasse/Methode auf der
-Typ-Variablen alle Methoden des angegebenen Obertyps verwendet werden.
-
-Ein Wildcard (`?`) als Typ-Parameter steht für einen beliebigen Typ, wobei die
-Typ-Variable keinen Namen bekommt und damit innerhalb der Klasse/Methode nicht
-zugreifbar ist.
+Typ-Parameter können durch **Bounds** eingeschränkt werden: `<T extends ...>`
+bedeutet, dass der Typ-Parameter `T` nach oben eingeschränkt wird ("upper bound").
+Durch `extends`-Bounds kann in einer Klasse bzw. Methode der Typ-Parameter so
+eingeschränkt werden, dass alle Methoden des Obertyps verwendet werden können.
+
+Ein **Wildcard** (`?`) steht für einen unbestimmten Typ. Ein Wildcard-Typ hat keinen
+Namen / ist nicht benennbar und ist innerhalb der Klasse/Methode nicht direkt
+zugreifbar. Wildcards können mit `? extends ...` nach oben ("upper bound") oder
+`? super ...` nach unten ("lower bound") eingeschränkt werden.
+
+Bei `? extends Bound` muss der konkrete Typ die Schranke selbst oder ein Subtyp
+davon sein. Bei `? super Bound` muss der konkrete Typ ein Supertyp (Obertyp) der
+angegebenen Schranke sein.
 :::
 
 ::: youtube
@@ -40,20 +41,29 @@ Cps<String> c;  // Fehler!!!
 
 -   Schlüsselwort `extends` gilt hier auch für Interfaces
 
--   Mehrere Interfaces: nach `extends` Klasse oder Interface, danach mit "`&`"
-    getrennt die restlichen Interfaces:
+-   Mehrere Interfaces: nach `extends` **eine** Klasse oder **ein** Interface,
+    danach mit "`&`" getrennt die restlichen Interfaces:
 
     ``` java
     class Cps<E extends KlasseOderInterface & I1 & I2 & I3> {}
     ```
 
-::: notes
+:::: notes
+Falls eine Klasse einem gemeinsamen Obertyp folgen soll, können mehrere Bound-Typen
+durch `&` verbunden werden. Der erste Bound kann eine Klasse (z.B. `Number`) sein;
+alle weiteren Bound-Typen müssen Interfaces sein. Wenn kein Klassen-Bound existiert,
+können alle Bound-Typen Interfaces sein.
+
+::: tip
 *Anmerkung*: Der Typ-Parameter ist analog auch mit `super` (nach unten)
-einschränkbar
+einschränkbar. Das schauen wir uns im Zusammenhang mit Vererbungsbeziehungen und
+Polymorphie im dritten Teil ["Generics3: Generics und
+Polymorphie"](generics3-polymorphism.md) noch genauer an.
+:::
 
 [Beispiel bounds.Cps]{.ex
 href="https://github.com/Programmiermethoden-CampusMinden/Prog2-Lecture/blob/master/lecture/java-classic/src/bounds/Cps.java"}
-:::
+::::
 
 # Wildcards: Dieser Typ ist mir nicht so wichtig
 
@@ -80,17 +90,58 @@ public class Wuppie {
     nutzbar ...
 
 ::: notes
+Die Wildcard `?` steht für einen unbekannten Typ. `List<?>` erlaubt `List`-Objekte
+jedes Typs, aber innerhalb der Methode kann man nicht sicher auf spezifische
+Eigenschaften des konkreten Typs zugreifen. `List<?>` ist also **nicht** eine "Liste
+von `Object`", sondern "Liste von unbekanntem Typ".
+
+-   Typvariable: "ich benenne den Typ und kann ihn mehrfach verwenden"
+-   Wildcard: "ich akzeptiere etwas Unbekanntes, kann es aber nicht benennen"
+
+Mit `List<? extends A>` erlaubt man Listen von Elementen, die `A` oder eine
+Unterklasse von `A` sind (*kovariant*, siehe auch Diskussion in ["Generics3:
+Generics und Polymorphie"](generics3-polymorphism.md)); man kann Elemente als `A`
+lesen/nutzen, aber nicht sicher als `A` hinzufügen (weil der echte Typ wg. des
+Wildcards unbekannt ist - es könnte ein beliebiger Untertyp von `A` sein).
+
 Weitere Eigenschaften:
 
 -   Durch Wildcard kein Zugriff auf den Typ
 -   Wildcard kann durch upper bound eingeschränkt werden
--   Geht nicht bei Klassen-/Interface-Definitionen
+-   Geht nicht bei Klassen-/Interface-Definitionen, hier wird eine Typ-Variable
+    benötigt
+
+Weitere Beispiele:
+
+-   `List<?>` - Typ der Listenelemente unbekannt, nur Methoden von `Object` nutzbar
+-   `List<? extends T>` - Typ der Listenelemente ist `T` oder eine Unterklasse von
+    `T`; Zugriff lesend mit den Methoden von `T` (außer `null`), Schreiben nur
+    eingeschränkt möglich (konkreter Typ unklar wg. `?` - es könnte eine Unterklasse
+    von `T` sein, und Schreiben von Elementen vom Typ `T` würde (wenn es erlaubt
+    wäre) dann zur Laufzeit schief gehen - Java fängt das aber zur Compilezeit ab)
+-   `List<? super T>` - Typ der Listenelemente ist `T` oder eine Oberklasse von `T`;
+    Zugriff schreibend möglich mit Werten vom Typ `T` und Untertypen, Lesen nur mit
+    `Object` (der konkrete Typ samt Schnittstelle ist unklar: es könnte eine
+    beliebige Oberklasse von `T` sein, die eine völlig unterschiedliche
+    Schnittstelle als `T` hat)
+
+=\> Das soll uns als erste Einführung von Bounds und Wildcards reichen. Wir werden
+überwiegend die `extends`-Bounds verwenden. Für eine genauere Diskussion von "Type
+Erasure" (TE) und "Producer extends, Consumer super" (PECS-Regel) sowie die
+Varianz-Diskussion siehe Lektion ["Generics3: Generics und
+Polymorphie"](generics3-polymorphism.md).
 :::
 
 \bigskip
 \bigskip
 
-@Bloch2018: Nur für Parameter und nicht für Rückgabewerte nutzen!
+@Bloch2018: Wildcards **meist** für Parameter; Rückgabewerte **möglichst** konkret
+typisieren.
+
+::: notes
+Generische Typen in Rückgabewerten sollten möglichst konkrete Typen oder Bounds
+verwenden, um Typ-Sicherheit zu wahren.
+:::
 
 # Hands-On: Ausgabe für generische Listen
 
@@ -115,9 +166,11 @@ public class X {
 }
 ```
 
-[**Hinweis**: Dieses Beispiel beinhaltet auch Polymorphie bei/mit generischen
-Datentypen, bitte vorher auch das Video zum vierten Teil "Generics und Polymorphie"
-anschauen]{.notes}
+::: notes
+**Hinweis**: Dieses Beispiel berührt auch Polymorphie bei/mit generischen
+Datentypen, vgl. dritter Teil ["Generics und
+Polymorphie"](generics3-polymorphism.md) anschauen.
+:::
 
 ::: notes
 ## Erster Versuch (*A* und *B* und *main()* wie oben)
@@ -130,7 +183,7 @@ public class X {
 }
 ```
 
-=\> **So gehts nicht!** Eine `List<B>` ist **keine** `List<A>` (auch wenn ein `B`
+=\> **So geht's nicht!** Eine `List<B>` ist **keine** `List<A>` (auch wenn ein `B`
 ein `A` ist, vgl. spätere Sitzung zu Generics und Vererbung ...)!
 
 [Beispiel wildcards.v1.X]{.ex
@@ -168,7 +221,7 @@ public class X {
 Das ist die Lösung. Man erlaubt als Argument nur `List`-Objekte und fordert, dass
 sie mit `A` oder einer Unterklasse von `A` parametrisiert sind. D.h. in der Schleife
 kann man sich auf den gemeinsamen Obertyp `A` abstützen und hat dann auch wieder die
-`printInfo`-Methode zur Verfügung ...
+`printInfo`-Methode (von `A`) zur Verfügung ...
 :::
 
 [Konsole wildcards.v3.X]{.ex