Folien - Die Complang

1
2015-05-28
Tagesprogramm
equals und hashCode (Nachtrag)
dynamisches Binden versus static und private
final Variablen, Klassen und Methoden
abstrakte Klassen und Methoden
PK
2
2015-05-28
equals und hashCode (Nachtrag)
PK
Aufgabe: Wozu equals?
Wozu benötigt man equals, obwohl es für Vergleiche auch == gibt?
A
Vergleiche mit == sind nur auf elementaren Typen sinnvoll.
B
Bei einem Vergleich mit == wird im Hintergrund equals aufgerufen.
C
Das System kann nicht wissen, wann zwei Objekte als gleich angesehen
werden sollen, und Operatoren kann man nicht selbst programmieren.
D
Gleichheit (equals) und Identität (==) sind nicht dasselbe.
3
2015-05-28
equals und hashCode (Nachtrag)
PK
hashCode
public int hashCode() {...}
gibt eine aus dem Objektinhalt errechnete (fast beliebige) Zahl zurück
wird von einigen Datenstrukturen (z.B. HashMap) benötigt
Bedingungen:
wenn x.equals(y) dann x.hashCode() == y.hashCode()
wenn x unverändert
dann liefern wiederholte Aufrufe von x.hashCode() gleiche Ergebnisse
→ wenn equals überschrieben dann auch hashCode überschrieben
Achtung:
aus x.hashCode() == y.hashCode() folgt nicht x.equals(y)
4
2015-05-28
dynamisches Binden versus static und private
PK
Dynamisches und statisches Binden
private static void test(IntContainer container) {
container.add(...);
// dynamisches Binden
}
IntContainer cont = new IntTree;
// statisches Binden
test(cont);
statisches Binden: Compiler weiß, welche Methode ausgeführt wird
→ Laufzeiteffizienz
dynamisches Binden: Laufzeitsystem bestimmt auszuführende Methode
→ Flexibilität und einfachere Wartbarkeit
5
2015-05-28
dynamisches Binden versus static und private
PK
static
public class X {
public int objectVar = 0;
// public vermeiden
public static int classVar = 0;
public void objectMeth() { objectVar++; classVar++; }
public static void classMeth() { classVar++; }
}
ohne static: gehört zu Objekt (X obj = new X();)
Zugriff über Objekt (obj.objectMeth(), obj.objectVar)
Methodenaufrufe im Allgemeinen dynamisch gebunden
mit static: gehört zu Klasse
Zugriff über Klasse (X.classMeth(), X.classVar)
Methodenaufrufe immer statisch gebunden
6
2015-05-28
dynamisches Binden versus static und private
private
Sichtbarkeit:
private nur in eigener Klasse sichtbar
public überall sichtbar
Binden von Methoden:
private Methoden immer statisch gebunden (auch ohne static)
Verwendung von Variablen:
private Variablen von Programmier(in) einfacher zu verstehen
private Variablen von Compiler manchmal besser optimierbar
PK
7
2015-05-28
dynamisches Binden versus static und private
PK
Aufgabe: Warum private Variablen?
Warum versteht man private Variablen meist einfacher als nicht-private?
A Weil niemand von draußen dazwischenpfuschen kann.
B Weil Klassenzusammenhalt und Objektkopplung gestärkt werden.
C Weil nur die Innensicht betrachtet werden muss.
D Weil ein geringerer Abstraktionsgrad immer einfacher ist.
8
2015-05-28
dynamisches Binden versus static und private
PK
Spezialfall: public Klassen
nicht geschachtelte Klassen:
in jeder Datei nur eine public Klasse (Dateiname ≈ Klassenname)
nur public Klassen von außen allgemein verwendbar
nicht-public Klassen nur im selben Paket verwendbar
public ist Normalfall
geschachtelte Klassen:
Sichtbarkeit so wie auch bei Variablen, Methoden, Konstruktoren
aber Einschränkungen von private können teilweise umgangen werden
trotzdem geschachtelte Klassen meist private (oder ohne Modifier)
9
2015-05-28
dynamisches Binden versus static und private
PK
Aufgabe: Sichtbarkeit von Klassen
Warum sind nicht geschachtelte Klassen meist public,
geschachtelte dagegen meist private?
A Weil nicht verwendbare Klassen nicht sinnvoll sind.
B Weil bei geschachtelten Klassen vorwiegend die Innenansicht zählt.
C Weil man nicht-public Klassen meist gut schachteln kann.
D Hat sich im Laufe der Zeit einfach so ergeben.
10
2015-05-28
final Variablen, Klassen und Methoden
PK
final auf Variable
Einschränkung der Änderbarbeit:
Wert einer final Variablen nach Initialisierung nicht änderbar
Besonderheiten von final Klassenvariablen:
final static Variablen vom Compiler sehr gut optimierbar
müssen bei der Deklaration initialisiert werden
können vorkommen, wo sonst nur Literale erlaubt sind
können in Interfaces deklariert werden (wo normale Variablen verboten sind)
sind häufig public
Sonderstellung meist durch Großschreibung hervorgehoben
public static final double PI = 3.14;
11
2015-05-28
final Variablen, Klassen und Methoden
final auf Methode
public class X {
public final void finalMethod() {...}
}
Methode kann in Unterklasse nicht überschrieben werden
darf nicht static sein
ermöglicht statisches Binden
kann in Obertyp (Interface oder Klasse) als nicht-final deklariert sein
einzelne final Methoden nur selten verwendet
PK
12
2015-05-28
final Variablen, Klassen und Methoden
final auf Klasse
public final class X {
public void finalMethod() {...}
}
keine Unterklassen von final Klassen erlaubt
alle Methoden in final Klasse sind final
oft sinnvoll
je nach Programmierstil gar nicht bis häufig eingesetzt
PK
13
2015-05-28
final Variablen, Klassen und Methoden
PK
Aufgabe: Bedeutung von final
Hat final auf Variablen dieselbe Bedeutung wie auf Klassen und Methoden?
A
Ja, weil in allen Fällen Änderungen vermieden werden.
B
Nein, weil es bei Variablen um dynamische Eigenschaften geht,
bei Klassen und Methoden dagegen um statische.
C
Nein, weil static final Variablen in der Praxis wichtig sind,
final Klassen und final Methoden dagegen nicht.
D
Ja, weil es um die finale Zielsetzung geht.
14
2015-05-28
abstrakte Klassen und Methoden
PK
abstract
public abstract class X {
private int v;
public void concreteMethod() {...}
public abstract void abstractMethod();
}
public abstract class Y extends X {
@Override
public void abstractMethod() {...}
}
abstrakte Klasse kann abstrakte (nicht implementierte) Methoden enthalten
kombiniert Eigenschaften von Interfaces mit denen von Klassen
new X() nicht erlaubt
abstrakte Klasse nur zusammen mit nicht-abstrakten Unterklassen sinnvoll
15
2015-05-28
Empfehlungen
private überall wo möglich, public überall wo nötig
nicht-geschachtelte Klassen fast immer public
static eher vermeiden, manchmal aber nötig
static final auf Variablen (= Konstanten) nutzen
final auf einzelnen Methoden eher vermeiden
final auf Klassen sinnvoll,
nicht-abstrakte Klassen so verwenden, als ob sie final wären
abstrakte Klassen eher meiden, Interfaces vorziehen
keine Angst vor dynamischem Binden
PK
16
2015-05-28
PK
Aufgabe: Begründung der Empfehlungen
Suchen Sie in Gruppen zu 2 bis 3 Personen Begründungen für die Empfehlungen.

Download Report