Info B VL 5: Klassenabhängigkeiten Objektorientiere Programmierung in Java 2003 Ute Schmid (Vorlesung) Elmar Ludwig (Übung) FB Mathematik/Informatik, Universität Osnabrück Info B VL 5: Klassenabhängigkeiten p.113
Klassenhierarchie Jede Klasse, die definiert wird, hat eine Oberklasse. Wenn keine Oberklasse (spezifiziert nach extends) angegeben wird, dann wird als Oberklasse java.lang.object vergeben. Als final deklarierte Klassen können nicht erweitert werden. z.b. java.lang.system Verhindern ungewünschter Erweiterungen (Compiler kann einige Optimierungen vornehmen) Info B VL 5: Klassenabhängigkeiten p.114
Klasse Object Wenn keine Oberklasse (spezifiziert nach extends) angegeben wird, dann wird als Oberklasse java.lang.object vergeben. Object ist eine Klasse mit speziellem Status: einzige Klasse, die keine Superklasse hat; alle Java Klassen erben die Methoden von Object. Vorteile einer solchen single rooted hierarchy : Jedes Objekt ist garantiert vom Typ Object. Klassen/Methoden, die auf allen Objekten arbeiten Für alle Objekte ist via Object garantiert, dass sie sinnvoll mit dem Laufzeit-System interagieren (z.b. Garbage Collection) Info B VL 5: Klassenabhängigkeiten p.115
Klassen-Baum In Java kann eine Klasse nur genau eine andere Klasse als Oberklasse haben. Im Gegensatz zu C++ gibt es keine Mehrfachvererbung Problem bei Mehrfachvererbung: Existiert dieselbe Komponente in mehr als einer Klasse, von der geerbt wird, muss geregelt werden, welche dieser Komponenten in die Unterklasse übernommen wird! Beispiel: java.lang.object und einige Unterklassen Info B VL 5: Klassenabhängigkeiten p.116
java.lang Boolean java.lang 1995-7, Charles L. Perkins http://rendezvous.com/java Cloneable Character Class ClassLoader FDBigInt local to package Serializable java.io-objects Compiler Math Number Process Byte Double Float Integer Long Object Runtime SecurityManager Short FloatingDecimal local to package String StringBuffer NullSecurityManager local to package System Runnable Thread ThreadGroup Throwable Void Error java.lang-errors Exception java.lang-exceptions ThreadDeath Info B VL 5: Klassenabhängigkeiten p.117
Vererbung und Konstruktoren (1) Erinnerung: PlaneCircle extends Circle // A new constructor method to initialize the new fields public PlaneCircle(double r, double x, double y) { super(r); // Invoke constructor of the superclass this.cx = x; // Initialize instance fields this.cy = y; } Info B VL 5: Klassenabhängigkeiten p.118
Vererbung und Konstruktoren (2) super(): Aufruf eines Oberklassen-Konstruktors (analog zu this(): Aufruf eines Klassen-Konstruktors) super() kann nur innerhalb einer Konstruktor-Methode benutzt werden Aufruf des Oberklassen-Konstruktors muss an erster Stelle in einem Konstruktor stehen (sogar vor der Deklaration lokaler Variablen) Argumente, die an super() übergeben werden, müssen mit der Signatur eines Oberklassen-Konstruktors übereinstimmen. Der entsprechende Konstruktor wird dann ausgewählt. Info B VL 5: Klassenabhängigkeiten p.119
Default-Konstruktoren (1) Java garantiert, dass immer, wenn eine Instanz einer Klasse erzeugt wird, eine Konstruktormethode der Klasse aufgerufen wird. Wenn die Klasse eine Unterklasse ist, ist ebenfalls garantiert, dass der Konstruktor der Oberklasse aufgerufen wird. Java muss sicherstellen, dass jede Konstruktormethode eine Konstruktormethode der Oberklasse aufruft. Wenn kein expliziert Aufruf angegeben ist, wird der Aufruf des Default Konstruktors super() eingefügt. Achtung: Wenn die Oberklasse keinen null-stelligen Konstruktor anbietet, erfolgt ein Compiler-Fehler! Info B VL 5: Klassenabhängigkeiten p.120
Default-Konstruktoren (2) Wenn eine Klasse gar keinen Konstruktor definiert, wird ein null-stelliger Default-Konstruktor erzeugt: public Klassen erhalten public Konstruktoren; alle anderen Klassen erhalten den default Konstruktor ohne Sichtbarkeits-Modifikator. Um zu verhindern, dass ein public Konstruktor eingefügt wird, sollte mindestens ein nicht-public Konstruktor definiert werden. Für Klassen, die nicht instantiiert werden sollen, sollte ein private Konstruktor definiert werden (kann nicht von ausserhalb der Klasse aufgerufen werden, verhindert automatische Einführung eines default-konstruktors.) (später: abstrakte Klassen) Info B VL 5: Klassenabhängigkeiten p.121
Konstruktor-Verkettung (constructor chaining) Wenn eine neue Instanz eines Objekts zur Klasse erzeugt wird, wird der entsprechende Konstruktor aufgerufen. Dieser ruft explizit oder implizt den Konstruktor der unmittelbaren Oberklasse auf usw., solange bis der Konstruktor der Klasse Object aufgerufen wird. Die Ausführung ist in umgekehrter Reihenfolge zum Aufruf, also zuerst wird Object() ausgeführt. Wann immer der Körper eines Konstruktors ausgeführt wird, ist sichergestellt, dass alle Felder der Oberklasse bereits initialisiert sind! Anmerkung finalizer chaining: finalize() Methoden werden nicht automatisch verkettet. super.finalize() Info B VL 5: Klassenabhängigkeiten p.122
Shadowing und Overriding Felder gleichen Namens und Methoden mit gleicher Signatur können in der Unterklasse neu definiert werden. Klassen- und Instanzfelder, sowie Klassenmethoden werden dabei überdeckt (shadowing) Instanzmethoden werden überschrieben (overriding) Info B VL 5: Klassenabhängigkeiten p.123
Verdecken von Feldern Beispiel: Weiteres Instanz-Feld in Klasse PlaneCircle, das die Distanz zwischen dem Kreismittelpunkt und dem Ursprung (0, 0) angibt, das r genannt wird, also dieselbe Bezeichnung hat, wie das Feld r (für Radius) in der Oberklasse Circle. class PlaneCircle extends Circle { public double r;... PlaneCircle(...) { // Pythagorean Theorem this.r = Math.sqrt(cx * cx + cy * cy); } } Info B VL 5: Klassenabhängigkeiten p.124
Zugriff auf verdecktes Feld r this.r super.r // Feld der aktuellen Klasse // dito // Feld der Oberklasse Alternativ: Cast des Objekts zur entsprechenden Oberklasse. ((Circle) this).r Klammerung beachten: erst Cast, dann Zugriff auf Feld! Info B VL 5: Klassenabhängigkeiten p.125
Zugriff via Casting in Klasse C: A +x B +x x // Field x in class C this.x // dito super.x // Field x in class B ((B)this).x // dito ((A)this).x // Field x in class A super.super.x // Illegal Syntax Bei Instanz von C: C +x C c = new C(); c.x ((B)c).x ((A)c).x // Field x of class C // Field x of class B // Field x of class A Info B VL 5: Klassenabhängigkeiten p.126
Überdecken von Klassen-F. analog zu Instanzfeldern Beispiel: PI mit höherer Genauigkeit class PlaneCircle extends Circle { public static final double PI = 3.14159265358979323846; } Innerhalb von PlaneCircle: PI PlaneCircle.PI super.pi Circle.PI Ausserhalb: qualifizierter Name // Field PI in class PlaneCircle // dito // Field PI in class Circle // dito Info B VL 5: Klassenabhängigkeiten p.127
Überdecken von K.-Methoden Klassen-Methoden werden nicht überschrieben sondern nur überdeckt. Klasse. methode (), OberKlasse. methode () haben in jedem Fall verschiedene Namen Info B VL 5: Klassenabhängigkeiten p.128
Überschreiben von Methoden Wenn in einer Klasse eine Instanz-Methode definiert wird, die dieselbe Signatur (Name, Parameter) hat wie eine Methode der Oberklasse, wird die Methode der Oberklasse überschrieben: Wenn die Methode bei einem Objekt der Klasse aufgerufen wird, dann wird die neue Methodendefinition aktiviert. Überschreiben von Methoden ist eine wichtige Technik der objekt-orientierten Programmierung. Etwas konstruierte Erweiterung des Circle-Beispiels: Ellipse als Unterklasse von Circle mit neuer Definition von area() und circumference(). Es ist wichtig, dass für ein Objekt der Klasse Ellipse immer die neuen Methoden zur Berechnung verwendet werden! Info B VL 5: Klassenabhängigkeiten p.129
Feldreferenz in vererbten Methoden Wird eine Methode vererbt und existieren die in ihr verwendeten Felder auch in der Unterklasse, so werden weiterhin die Felder in der Oberklasse referenziert! class A { int x = 1; int y = 2; int f() { return x+y; } } class B extends A { int x = 21; int y = 22; } public class OverShad { public static void main (String[] args) { B myb = new B(); A mya = new A(); System.out.println(myB.f()); System.out.println(myA.f()); } } Info B VL 5: Klassenabhängigkeiten p.130
Dynamic Method Lookup Woher weiss der Compiler, ob er die Methode zur Oberklasse A oder zur Unterklasse B aufrufen soll, wenn beispielsweise ein Array von A Objekten definiert wurde, in dem manche Objekte zur Klasse B gehören können? Kann er nicht wissen: Code, der dynamisches Method Lookup zur Laufzeit benutzt: Interpreter prüft Typ eines Objektes und ruft die entsprechende Methode auf. auch als Virtual Method Invocation bezeichnet (in C++) Info B VL 5: Klassenabhängigkeiten p.131
Statisches Method Lookup (1) Schneller, wenn kein dynamic method lookup zur Laufzeit benötigt wird. Wenn eine Methode mit dem final Modifikator deklariert ist, heißt das, dass die Methode nicht von einer Unterklassen-Methode überschrieben werden darf. Der Compiler weiss bereits, welche Version der Methode gemeint ist, und dynamisches Lookup ist damit unnötig. Info B VL 5: Klassenabhängigkeiten p.132
Statisches Method Lookup (2) Für bestimmte Methoden kann das Java-Laufzeitsystem dynamic method lookup vermeiden: Alle Methoden einer final deklarierten Klasse sind final: also ist bekannt, für welche Klasse der Aufruf erfolgt. Alle private Methoden können generell nur in der Klasse selbst aufgerufen werden: damit ist ebenfalls bekannnt, für welche Klasse der Aufruf erfolgt. private Methoden sind implizit final und können nicht überschrieben werden. static (Klassen)-Methoden werden generell nicht überschrieben (sondern überdeckt). Info B VL 5: Klassenabhängigkeiten p.133
Aufruf überschriebener Methoden (1) Aufruf überschriebener Methoden ist syntaktisch ähnlich zu Zugriff auf überdeckte Felder: super. methode () Aufruf einer überschriebenen Methode kann nicht mit Casting (((A)this).f()) realisiert werden! Modifizierte Form von dynamischem Method Lookup bei super: Gehe zur direkten Oberklasse derjenigen Klasse, innerhalb derer super aufgerufen wird. Wenn die Methode dort definiert ist, verwende sie, ansonsten gehe zur direkten Oberklasse dieser Klasse etc. super spricht die Methode an, die unmittelbar überschrieben wurde. Info B VL 5: Klassenabhängigkeiten p.134
Aufruf überschriebener Methoden (2) super bezieht sich immer auf die unmittelbare Oberklasse der Klasse, in der der Aufruf steht. Beispiel: super.f() in OverrideTest bezieht sich auf die Klasse Object! Überdeckte Klassen-Methoden können ebenfalls durch super angesprochen werden. (Hier erfolgt generell kein dynamic lookup.) class A { // Define a class named A int i = 1; // An instance field int f() { return i; } // An instance method static char g() { return A ; } // A class method } class B extends A { // Define a subclass of A int i; // Shadows field i in class A int f() { // Overrides instance method f in A i = super.i + 1; // It can retrieve A.i like this return super.f() + i; // It can invoke A.f() like this }} Info B VL 5: Klassenabhängigkeiten p.135
Overloading Nicht verwechseln mit overriding! Überladen (von Operatoren bzw. Methoden): verwenden des selben Namens mit verschiedenen Signaturen (Typen) auch ad hoc Polymorphismus Info B VL 5: Klassenabhängigkeiten p.136
Operator-Overloading Beispiel: monadisches und diadisches -; + für Integers, Floats, Strings Java erlaubt dem Benutzer kein Überladen von primitiven Operatoren, aber Überladen von Methoden (und Konstruktoren). Vorteil von Overloading: Bedeutung eines Symbols im Kontext spart die Einführung zusätzlicher Symbole. Beispiel: Definition von für komplexe Zahlen. Vergleiche natürliche Sprache (das vermisste Buch finden, sein Glück finden). Nachteil von Overloading: Es ist nicht mehr ohneweiteres nachvollziehbar, was ein Operator wirklich tut (unklare Semantik), wenn primitive Operatoren vom Benutzer überladen werden dürfen (Kritik an C++). Info B VL 5: Klassenabhängigkeiten p.137
Überladenes + Beispiel: a b Intuitiv, wenn a und b vom gleichen primitiven numerischen Typ sind: int int int, float float float. Verschiedene Optionen für char char: liefert den String aus den beiden Zeichen, liefert die Summe der Ordnungszahl der Zeichen,... Häufig sinnvoll: wenn verschiedene numerische Typen beteiligt sind, wird zunächst auf den größeren Typ ge-castet: int float float. Was tun bei char short? (in Java haben beide 16 Bit)? Eventuell Verlust der Kommutativität: Vorrang des ersten Arguments, also könnte char short einen anderen Ergebnistyp liefern als short char. Was ist die Intuition für Stack Vector? Info B VL 5: Klassenabhängigkeiten p.138
Operator-Overloading in Java Arithmetische Operatoren und Vergleichsoperatoren sind für numerische Typen definiert (alle primitiven Typen ausser boolean) Es ist zulässig, dass ein Operator Argumente verschiedenen Typs miteinander verknüpft. Dabei erfolgt ein implizites Casting zu dem größeren Typ, mindestens zu int (widening, siehe Tabelle). Rückgabetyp bei arithmetischen Operatoren: double wenn mindestens ein Argument double, float wenn mindestens ein Argument float, long wenn mindestens ein Argument long, int sonst (auch, wenn beide Argumente byte, short oder char sind). Dabei werden zuerst die impliziten Casts auf den Operanden durchgeführt und dann der Operator angewendet. Info B VL 5: Klassenabhängigkeiten p.139
+ für String Der Operator + (und +=) ist zusätzlich für String-Objekte definiert. Wenn mindestens eines der Argumente String ist, wird das andere Argument zu String konvertiert. Klammern sind häufig notwendig: System.out.println("Total: " + 3 + 4); // Total: 34 nicht 7 (Klammern (3 + 4): erst Addition auf Zahlen) Für String Object wird Object in String umgewandelt, indem die tostring()-methode des Objekts angewendet wird. Achtung: Die für Object definierte tostring() Methode liefert die Referenz-Adresse des Objekts als String. Falls andere Information gewünscht wird, muss diese Methode überschrieben werden. Info B VL 5: Klassenabhängigkeiten p.140
Method-Overloading In Java musste Method-Overloading zugelassen werden, da es möglich sein sollte, mehr als einen Konstruktor für eine Klasse zu definieren. Überladene Methoden müssen sich eindeutig durch ihre Signatur unterscheiden: Anzahl, Reihenfolge und Typ der Argumente. Eine blosse Unterscheidung durch verschiedene Rückgabe-Typen ist unzulässig: void f() {}; int f() {}; Könnte nur klappen, wenn der Compiler eindeutig aus dem Kontext bestimmen kann, welche Methode gemeint ist, z.b. int x = f(); Auch bei Methoden mit unterschiedlichen Signaturen kann es Probleme geben, die gemeinte Methode zu identifizieren (Compiler-Fehler) Info B VL 5: Klassenabhängigkeiten p.141
Beispiel public class Overloading { public static String f(string s, Object o) { return s + o; } public static Object f(object o, String s) { return (Object) (o + s); } public static void main(string[] args) { System.out.println(f("Die Zahl ist ", (Object)"17")); System.out.println(f((Object)"17", " ist eine Zahl")); // System.out.println(f("Hello", "World")); // ambiguous!! } } Info B VL 5: Klassenabhängigkeiten p.142
Polymorphismus (1) In der objekt-orientierten Programmierung meint Polymorphismus, dass Variablen deklariert werden können, die zur Laufzeit auf Objekte verschiedener Klassen verweisen können. Vorteil: Eine Methode setcolor() kann für beliebige Shape-Objekte definiert werden. Egal, ob die Methode zur Laufzeit zu einem Circle- oder einem Rectangle-Objekt gehört, sie kann auf jeden Fall angewendet werden. Dadurch wird Duplizierung von Code vermieden! Keine Kenntnis nötig, welche Unterklassen von Shape konkret existieren. Info B VL 5: Klassenabhängigkeiten p.143
Shapes Shape + setcolor Shape s; s.setcolor(); Upcasting Circle + area + circumference + diameter Rectangle + area + circumference + issquare Triangle + area + circumference +... Info B VL 5: Klassenabhängigkeiten p.144
Polymorphismus (2) Wird eine Methode f() in der Oberklasse definiert, so kann sie in der Unterklasse überschrieben werden. Für ein Shape-Objekt, das ein Circle ist, wird dann seine spezifische Methode verwendet. Polymorphismus kann nur zusammen mit dynamic binding (auch late binding) realisiert werden. Info B VL 5: Klassenabhängigkeiten p.145