Typverträglichkeit bei Feldern mit Klassentyp als Basistyp

Transkript

1 Typverträglichkeit bei Feldern mit Klassentyp als Basistyp zur Erinnerung: short [] ashort={1,2,3; int [] aint; //aint = asort; // Typfehler Aber B Subtyp von A, dann B[] Subtyp von A[] Problematisch: Account[] a = new Account[10]; Checking[] c = new Checking [5]; a=c; a[0]= c[0]; a[0] = new Account(4999); bedeutet? Exception in thread "main" java.lang.arraystoreexception: hs / fub - alp

2 Sichtbarkeit, Verdecken und Ersetzen Sichtbarkeit: definiert durch Modifikatoren und Vererbung Sichtbarkeitsmodifikatoren (Klassen): keiner public final Klasse ist nur aus demselben package erreichbar. Klasse ist von überall erreichbar. Klasse ist final, d.h. kann nicht vererbt werden. Es können keine Unterklassen abgeleitet werden. (Eigentlich kein Sichtbarkeitsmodifikator: public final überall sichtbar und nicht erweiterbar) hs / fub - alp

3 Sichtbarkeitsmodifikatoren für Attribute und Methoden: keiner public private Variable ist nur innerhalb der eigenen Klasse und des package erreichbar, zu dem sie gehört. Variable ist überall dort erreichbar, wo auch die Klasse erreichbar ist, zu der sie gehört. Variable ist nur innerhalb der eigenen Klasse erreichbar. protected Variable ist nur innerhalb der eigenen Klasse und des package erreichbar, zu dem sie gehört, ferner in Unterklassen. hs / fub - alp

4 Sichtbarkeit verdeckender oder überschreibender Namen darf nicht gegenüber den verdeckten / ersetzten verringert werden. Deshalb nur folgende Änderungen erlaubt: protected public leer public, protected aber hs / fub - alp

5 eine gewisse Vorsicht ist angebracht: class C1 { private int foo() {return 0; int bar(){ return foo(); class D1 extends C1 { int foo(){return 1; public static void main(string[] args) { D1 c = new D1(); System.out.println(c.bar()); und ohne private? s.u. überschreibt private foo() wird geerbt und bezieht sich auf private foo(), was nicht direkt verwendet werden darf! hs / fub - alp

6 Verdecken (hiding) und Ersetzen (Überschreiben, overriding) Betrachten hier nur vertikale Kollision in der Vererbungshierarchie Attribute: Verdecken wie in Blockstruktur (hiding) (aber gleiche Namen/Typ erlaubt.) Methoden: verschiedene Signatur: Überladen (overloading) gleiche Signatur, beide statisch Verdecken gleiche Signatur beide nichtstatisch Ersetzen (overriding) sonst Fehler (*) Implementieren von mehr als einer Schnittstelle kann auch zu Namenskollision führen. hs / fub - alp

7 Verdecken von Attributen (1) class A { boolean bool=true;... class B extends A { int bool=1;... B b = new B(); A a = b; a.bool=false; System.out.println(a.bool + ((B)a).bool); > false > 1 b bool: false Statischer Typ bestimmt Attribut! a statischer Typ von a ist A, dynamischer B hs / fub - alp

8 Verdecken von Attributen (2) Auch statische Attribute werden verdeckt: class C { boolean bool=false; static int i=10; class D extends C { static int bool; // hides boolean boolean i; // hides static int i static void op(){ System.out.println ("op() in C: i="+i); //... static void op(){ // i=1; //can only use static //members! but i is now dynamic System.out.println("op() in D: bool=:"+bool); D dd = new D(); C c = dd; // c.bool= 1; error: static type of c.bool is boolean c.bool = true; dd.bool = 1; ((D)c).bool = 22; c.i = 11; hs / fub - alp

9 Statischer Typ bestimmt Attribut! D d = new D(); C c = d ; // c.bool= 1; error c.bool = true; d.bool = 1; ((D)c).bool = 22; c.i = 11; d.i = true; D e = new D(); d c e bool i bool false true true false C D static fields i bool 221 i hs / fub - alp

10 Verdeckung statischer Methoden wie bei Attributen: der statische Typ bestimmt die auszuführende Methode. D dd = new D(); C c = dd; c.op(); ((D)c).op(); dd.op(); class C { boolean bool=false int i=11; static void op(){ System.out.println ("op() in C: i="+i); Ausgabe: > op() in C: i= 11 > op() in D: bool=22 > op() in D: bool=22 class D extends C { static int bool = 22; static void op(){ System.out.println ("op() in D: bool="+bool); hs / fub - alp

11 Polymorphie: Methoden gemäß dynamischem Typ ausführen Class Saving extends Account{ void compinterest(){ //for saving accounts Class Checking extends Account{ void compinterest(){ //for checking accounts! Account a = new Saving(..); a.compinterest(); a = new Checking(..); a.compinterest(); Zur Laufzeit (dynamisch) wird die Methode gewählt, die das Objekt besitzt, auf die a verweist, nicht die durch den statischen Typ (hier Account) von a bestimmte. hs / fub - alp

12 Po ly mor'phie, die; -, keine Mehrzahl 1.Vielgestaltigkeit, Verschiedengestaltigkeit 2. [ ] (*) Diese Art der Polymorphie ist nur im Zusammenhang mit Vererbung definiert. - Vererbung von Klassen, - Vererbung von Schnittstellen, - Implementierung von Schnittstellen durch Klassen. -Sammelbegriff: Inklusions- (Einschluss-) Polymorphie (inclusion polymorphism) Andere Arten von Polymorphie?? (*) Langenscheidt Fremdwörterbuch (digitale Ausgabe) hs / fub - alp

13 Polymorphie in Java Zugriffsregel: für nichtstatische Methoden ist der Typ des Objekts entscheidend für Attribute und statische Methoden der Typ des der Verweisvariablen (bzw. Parameter) Grund dafür: Effizienter Attributzugriff - schon beim Übersetzen steht die Speicheradresse fest - Adressen der Methoden werden sowieso dynamisch ermittelt Regeln können explizit umgangen werden z,b, durch Typanpassung. Nicht in allen OO Sprachen so. Regeln beachten! hs / fub - alp

14 Dynamischer Methodenaufruf Rechteck f 2DGeoO g Kreis c a b Felder a,b,.. Felder a,b,.. flaeche() static farbe()... Referenzen Objekte (nur Werte!) Klasse d e Felder r,.. Felder r,.. flaeche() farbe()... Code für diese flaeche() Genaugenommen: Klassen- Deskriptoren, die die Adressen der Methoden enthalten Das ist die Kreisfläche! also: völlig anderer Code Code farbe() Code für jene flaeche() Zur Übersetzungszeit ist nicht bekannt, ob f bzw. g auf ein Rechteck oder einen Kreis zeigen. Stattdessen wird g.flaeche() so ausgeführt: (1) Klassendeskriptor lesen (2) dort Adresse a von richtiger flaeche() finden hs / fub - alp

15 Generizität (*) Unterschied zu Inklusionspolymorphie? Vergleiche Generizität in Haskell! Generizität = parametrische Polymorphie Typparameter ermöglichen das Schreiben von Programmen ohne auf einen Typ oder die Vererbungsbeziehung von Typen festgelegt zu sein. Vor Ausführung des Programms: Typparameter durch konkreten Typ ersetzen. (*) hier nur extrem knapp behandelt. Details ALP3 bzw. Literatur hs / fub - alp

16 Zwei Beispiele: a) Für Algorithmus ist der konkrete Typ belanglos append :: [a]-> [a] -> [a] append [] xliste = xliste append (y:yliste) xliste = x:(append yliste xliste) b) Konkrete Typen müssen zueinander passen, welche das sind spielt keine Rolle. map :: (a -> b) -> [a] -> [b] map f [] = [] map f (x:xlist) = (f y): map f xlist Objektorientierte Sprachen? hs / fub - alp

17 Generizität.. gibt es in Eiffel, C++ ("Template-Mechanismus"), C# (seit.net 2.0) und Java (seit 1.5) Generische verkettete Listen in Java: public class LListGeneric <G>{ private ListNodeGen <G> head, tail, current; private ListNodeGen <G> sentinel = new ListNodeGen<G>(null); public void add(g o){ // insert at front head = new ListNodeGen <G>(o,sentinel.next); sentinel.next=head; size++; typarametrisierte Methode hs / fub - alp

18 Verwendung von generischen Listen map (2*) [1..10] Typparameter a, b durch integer ersetzen. Java: public static void main(string[] args) { LListGeneric<Integer> ll; int maxelem = 17; ll= new LListGeneric<Integer>(); for (int i=1;i<=maxelem;i++) ll.add(new Integer(i)); hs / fub - alp

19 Problematisch ist die Interferenz mit Vererbung. Zum Beispiel: Aus B verträglich mit A folgt nicht List<B> verträglich mit List<A> List<A> a = new List<A>(); List<B> b = new List<B>(); a.head = new A(); a.head = new B(); // vgl. Felder Komplexität des Typsystems erhöht sich deutlich. hs / fub - alp

20 Übersicht Polymorphie Polymorphie Überladen Universelle Polymorphie ad hoc Typwandlung (coercion) Generizität Inklusionspolymorphie hs / fub - alp

21 Ergänzung (*) Innere Klassen Manchmal nützlich, Klassen Inside nicht auf dem "Toplevel" zu definieren, sondern innerhalb einer anderen Klasse Outside. 1. statische innere Klassen class A{ static class B{... Kein Problem: B ist Attribut von A mit Zugriff auf alle statischen Eigenschaften von A (aber nicht die dynamischen) (*) in der Literatur nachlesen hs / fub - alp

22 2. Elementklassen class A{ class B{... B b = new B(); A a = new A(); B b = a.new B(); B ist Attribut von A das erzeugt werden muss und Zugriff auf die nichtstatischen Eigenschaften von A hat. Von "außen" kann ein B-Objekt nur erzeugt werden, wenn ein zugehöriges A-Objekt a existiert. hs / fub - alp

23 2. Lokale und anonyme innere Klassen class A{ public static void main( String args[] ) { Point p = new Point( 10, 12 ) { public String tostring() { return "(" + x + "," + y + ")"; ; System.out.println( p ); // (10,12) Hier wird ein einziges Objekt erzeugt, das über p verwendet werden kann. new A {<anonyme Klasse>: anonyme ist Unterklasse von class A -im Beispiel: { überschreibt tostring() Wenn interface A (Schnittstelle), wird sie von {... implementiert. Variante: benannte lokale Klasse: {..class B{...new B; hs / fub - alp