Teil 2: Objektorientierte Programmierung 2.3 Modularisierung Prof. Dr. Max Mühlhäuser FG Telekooperation TU-Darmstadt

Transkript

1 Grundzüge der Informatik Teil 2: Objektorientierte Programmierung 2.3 Modularisierung Prof. Dr. Max Mühlhäuser FG Telekooperation TU-Darmstadt

2 Java-Pakete: Überblick Pakete (Packages) ermöglichen: Bündeln von Klassen, die zu einem gemeinsamen Aufgabenbereich gehören Vermeiden von potentiellen Namenskonflikten Klassennamen müssen innerhalb eines Pakets eindeutig sein Ein Klassenname kann in anderen Paketen erneut verwendet werden Definition und Kontrolle von Zugriffen und Sichtbarkeit 2

3 Java-Pakete: Überblick Jede Klasse (und jede Schnittstelle) in Java ist Bestandteil genau eines Pakets Ist eine Klasse (oder eine Schnittstelle) nicht explizit einem Paket zugeordnet, dann gehört es implizit zu einem default-paket Paket-Hierarchie Pakete sind hierarchisch gegliedert ein Paket kann Unterpakete besitzen, die selbst wieder in Unterpakete aufgeteilt sind, usw. Punktnotation der Paketnamen paket.unterpaket1.unterpaket11.klasse Paketnamen sind sehr wichtig bei der Suche nach Klassen 3

4 Java-Pakete Zu welchem Paket eine Klasse gehört, wird in der zugehörigen.java-datei bestimmt Der Quelltext eines gesamten Java-Programms kann über mehrere Klassen und damit Dateien verteilt sein Typdefinitionen einer Datei können auch zu mehreren Programmen gehören (d.h. von ihnen verwendet werden) Wiederverwendung 4

5 Struktur einer.java-datei: Java-Pakete Source-File = [Package-Declaration] {Import-Declaration} { Class-Definition Interface-Definition }. Package-Declaration = "package" Package-Name ";". Package-Name = Identifier { "." Identifier }. Vor der Package-Declaration dürfen nur Kommentare und Leerzeilen stehen Nur eine Package-Declaration pro Datei Wird die Package-Declaration weggelassen, ist die Datei Element des Default-Pakets 5

6 Java-Pakete Paketdeklaration Der selbe Paketname kann in mehreren Dateien verwendet werden Typdefinitionen, die zu einem Paket gehören, können somit über mehrere Übersetzungseinheiten verteilt sein Kürzere Übersetzungszeiten Arbeitsaufteilung in großen Projekten wird unterstützt Paketname wird implizit jedem im Paket enthaltenen Typnamen vorangestellt Abtrennung durch einen Punkt Der vollständige Name einer Klasse ist packagename.classname 6

7 Import-Deklaration Java-Pakete Import-Declaration = "import" Package-Name "." (Class-Name "*") ";". Wird der Klassenname angegeben, kann auf diesen künftig ohne Angabe des Pakets zugegriffen werden Wird * angegeben, können sämtliche im Paket enthaltene Klassen ohne weitere Angabe des Paketnamens verwendet werden 7

8 Java-Pakete Nutzen von Klassen eines anderen Pakets Volle Qualifizierung der Klasse, z.b. java.util.random einzufall = new java.util.random(); import-anweisung, z.b. import java.util.random;... Random einzufall = new Random(); 8

9 Java-Pakete Nutzen von Klassen eines anderen Pakets import paket.* : alle Klassen des Pakets, z.b. import java.util.*;... Random einzufall = new Random(); Schlechter Stil: für Leser ist unklar, was gebraucht wird Nur wenn (fast) alle Typdefinitionen eines Pakets benötigt werden, ist die *-Form angebracht 9

10 Import von Paketen Durch die Verwendung von Import-Anweisungen können Namenskonflikte auftreten Existieren identische Typnamen in mehr als einer der importierten Pakete, muss bei der Verwendung dieser Namen immer das Paketpräfix benutzt werden, z.b. import java.awt.*; // Enthaelt eine Klasse List import java.util.*; // Enthaelt ebenfalls eine // Klasse List... java.util.list list; // Paketname verwenden um festzustellen, // welche List verwendet wird 10

11 Import von Paketen In jeder Datei werden einige Pakete automatisch importiert: Das eigene Paket Das vordefinierte Paket java.lang enthält elementare Klassen wie z.b. Object, String 11

12 Import von Paketen Zu Java gehören eine Vielzahl vordefinierter Pakete, die mit dem JDK ausgeliefert werden, z.b.: java.applet Applet-Unterstützung java.io Ein- und Ausgabe für Dateien java.net Netzwerkprogrammierung java.util Hilfsklassen, z.b. Zufallszahlengenerator java.util.zip Hilfsklassen zum Verwenden von.zip-dateien usw. 12

13 Paketbenennung Paketnamen spielen eine zentrale Rolle für die Vermeidung oder Auflösung von Namenskonflikten sollten bedeutungstragend sein sollten möglichst eindeutig sein, am besten weltweit Konventionen zur Konstruktion weltweit eindeutiger Paketnamen Der Paketname enthält als Präfix den Internet-Domain- Namen der Hersteller in umgekehrter Reihenfolge Bindestriche sind in Paketnamen nicht erlaubt Beispiele URL der Firma Sun: sun.com Klassen der Firma Sun: com.sun.paket1.paket11.klasse URL der TU Darmstadt: informatik.tu-darmstadt.de Klassen der TU Darmstadt: de.tudarmstadt.informatik.paket1.paket11.klasse 13

14 Paketbenennung Paketnamen und Dateisystemstrukturen Für die Zuordnung von Paketnamen zu Dateinamen müssen Punkte im Paketnamen durch das Trennzeichen des Betriebsystems ersetzt werden UNIX: / Slash Microsoft-Betriebsysteme \ Backslash Beispiel: Paketname: kilian.hobby.raytracer Zugehöriger UNIX-Verzeichnisname: kilian/hobby/raytracer Zugehöriger Windows-Verzeichnisname: kilian\hobby\raytracer 14

15 Suche nach Paket- und Typnamen Ein Paketname wird als relativer Pfadname aufgefasst Die Betriebssystemvariable CLASSPATH definiert die Verzeichnisse, ab denen ein Paketname gesucht wird Einträge in einer CLASSPATH-Spezifikation können Verzeichnisse, ZIP- oder JAR-Dateien sein, die Klassen enthalten Beispiel UNIX-Betriebssystem: CLASSPATH=.:/home/joe/classes:/usr/local/classes.zip Beispiel Windows-Betriebssystem Trennt einzelne Verzeichnisse set CLASSPATH=.;C:\joe\classes;D:\local\classes.zip 15

16 Suche nach Paket- und Typnamen Die Verzeichnisse aus CLASSPATH sind die Ausgangspunkte für den relativen Pfadnamen, der über den Paketnamen festgelegt ist Die Verzeichnisse aus CLASSPATH werden in der angegebenen Reihenfolge durchsucht (von links nach rechts) Prinzipiell können mehrere Verzeichnisse existieren, die über einen Paketnamen gefunden werden können Keine gute Idee, da es dann von der in CLASSPATH definierten Reihenfolge abhängt, welche Pakete (und damit Typdefinitionen) tatsächlich verwendet werden 16

17 Suche nach Paket- und Typnamen Eigene Pakete Der Compiler löst den hierarchischen Namen in eine Kette von Unterverzeichnissen auf Am Ende der Kette liegt die Quelldatei Neben der Quelldatei wird auch die Klassendatei in diesem Unterverzeichnis abgelegt 17

18 Suche nach Paket- und Typnamen Der Java-Compiler übersetzt eingebundene Quelldateien, die noch nicht übersetzt sind, automatisch mit, z.b.: package mypackage; import mypackage.subpackage.someclass; class MainClass { } private SomeClass xy; public static void main(string[] args) { }... Wird javac mypackage\mainclass.java aufgerufen, wird automatisch auch mypackage\subpackage\someclass.java compiliert 18

19 Kapselung Kapselung und Geheimnisprinzip (information hiding) Objekte kommunizieren miteinander über wohldefinierte Schnittstellen Jedes Objekt stellt den anderen Objekten nur die nötige Menge an Operationen zur Verfügung Verdeckt hinter dieser Schnittstelle: die interne Struktur und die aktuellen Werte der Attribute sowie die Implementierung der Operationen Was geht Dich meine Post an? 19

20 Kapselung Mehr Abstraktion, einfacher von den Klienten zu benutzen nicht geheim halten, sondern von unnötigen Details befreien! Verhindert unerlaubte Zugriffe von kritischen Daten Anpassbarkeit Zugriff nur über öffentliche Methoden (Schnittstelle) Realisierung der Schnittstelle ist austauschbar, ohne Änderungen in anderen getesteten und bewährten Klassen nachzuziehen 20

21 Kapselung Eine Analogie Bankautomaten haben eine Bedienungsschnittstelle Das Betätigen einer Funktionstaste - z.b. Auszahlung - entspricht dem Aufruf einer Methode des Bankautomat-Objekts Frau Schmidt ist der Sender und der Automat der Empfänger Die Eingabe des Betrags entspricht der Parametereingabe 21

22 Kapselung Frau Schmidt sieht nur die Bedienungsschnittstelle Sie hat keine Information darüber, wie der Automat intern aufgebaut ist Für sie ist es unmöglich, den Geldbehälter des Automaten anzuschauen, ob genügend 50 Euro- Scheine darin enthalten sind, und ihren Betrag selbst herauszuholen. 22

23 Kapselung leichter zu verwenden Frau Schmidt möchte die Details der internen Realisierung gar nicht wissen! verhindert unerlaubte Angriffe Nicht jeder sollte auf den Geldbehälter des Automaten zugreifen können! schützt Klienten vor Veränderungen in der Realisierung des Objektes Die Bank kann einen neuen Automaten aufstellen Solange die Bedienungsschnittstelle dieselbe bleibt, können Kunden die neue Implementierung ohne weiteres benutzen 23

24 Geheimnisprinzip class Auto { // Schnittstelle public Auto(String farbe, int geschwindigkeit, int tankinhalt) { this.tankinhalt = tankinhalt; this.farbe = farbe; this.geschwindigkeit = geschwindigkeit;... } // end constructor... // Implementierung (Modell) private int tankinhalt, geschwindigkeit; private String farbe;... } // end class Auto Schnittstelle 24

25 Geheimnisprinzip class Auto { // Schnittstelle public Auto(String farbe, int geschwindigkeit, int tankinhalt) { this.tankinhalt = tankinhalt r farbe = rot(f); = f; g = gruen(f);... this.geschwindigkeit = geschwindigkeit;... } // end constructor... // Implementierung (Modell) private int tankinhalt, geschwindigkeit; private int String r, g, farbe; b;... } // end class Auto 25

26 Geheimnisprinzip class Auto { // Schnittstelle public Auto(String farbe, int geschwindigkeit, int tankinhalt) { this.tankinhalt = tankinhalt r farbe = rot(f); = f; g = gruen(f);... this.geschwindigkeit = geschwindigkeit;... } // end constructor... // Implementierung (Modell) private int tankinhalt, geschwindigkeit; private int String r, g, b; farbe;... } // end class Auto Änderung der Implementierungsentscheidung nach außen nicht sichtbar Alle Klienten können unverändert weiter verwendet werden 26

27 Geheimnisprinzip Möglichkeiten zur Realisierung des Geheimnisprinzips Vertrauen: andere wissen, dass Geheimnisprinzip eine gute Idee ist sie sollten nur über Methoden auf Daten eines Objekts zugreifen Aber: wenn das jemand nicht weiß? Versehentliche Zugriffe? Dokumentieren, welche Elemente wichtig sind Bösartige Zugriffe auf das Modell? (Grund für viele Sicherheitslücken von Programmen) Programmiersprache muss Geheimnisprinzip unterstützen 27

28 Geheimnisprinzip Java bietet integrierte Sichtbarkeitsmodifikatoren Definieren Zugriffsrechte auf Elemente Die Programmiersprache erlaubt Zugriff auf Elemente nur für Klassen, die auch dürfen In EBNF als Visibility geschrieben (siehe Teil 1.4, 2.1) Sowohl Methoden, Konstruktoren und Attribute als auch Klassen können eine definierte Sichtbarkeit haben Modifikatoren für Methoden, Konstruktoren und Attribute (Wiederholung): "public" "protected" "private" (oder kein Modifikator) Modifikatoren für Klassen (Wiederholung): "public" (oder kein Modifikator) 28

29 Zugriffsrechte und Sichtbarkeit implizit (Ohne Angabe eines Modifikators) Das Element ist nur innerhalb des Pakets sichtbar, in dem die Klasse definiert ist Das gilt für Subklassen und Nicht-Subklassen Von außerhalb des Pakets ist kein Zugriff möglich 29

30 Zugriffsrechte und Sichtbarkeit private: Nur Objekte der selben Klasse dürfen auf das Element zugreifen weder andere Klassen, noch Erben class A { private void op1() {... } public void op2(a anaobject) { } }... anaobject.op1();... // OK 30

31 Zugriffsrechte und Sichtbarkeit protected: Alle Klassen im gleichen Paket dürfen auf das Element zugreifen, sowie alle Klassen, die davon erben (egal in welchem Paket definiert) public: Zugriff von überall erlaubt 31

32 Zugriffsrechte und Sichtbarkeit private implizit protected public Eigene Klasse Erben im gleichen Paket Im Paket Erbe in anderem Paket Im anderen Paket 32

33 Zugriffsrechte und Sichtbarkeit package package A; A; A; A; class public class AA AA { AC AC extends AA AA {{ { // public int intone; // one, one, two, two, four four } int inttwo; } two; private void voidthree() {{ }} package protected void voidfour() {{ } B; B; } class } BA BA extends AA AA {{ } // // one, one, four four }} package A; A; class AB AB {{ // // one, one, two, two, four four }} package B; B; class BB BB {{ // // one one }} 33

34 Zugriffsrechte und Sichtbarkeit UML-Darstellung von Sichtbarkeit UML bietet die Sichtbarkeiten public, protected und private public-elemente werden durch ein + gekennzeichnet protected-elemente werden durch # gekennzeichnet private-elemente werden durch gekennzeichnet Keine Kennzeichnung der Sichtbarkeit = Sichtbarkeit undefiniert Klassenname -privateattribute : Klasse1 #protectedattribute : int +publicmethode(x: int) : boolean 34

35 Zugriffsrechte und Sichtbarkeit Zugriffskategorien beim Überschreiben Beim Überschreiben einer Methode wird die geerbte Zugriffskategorie zunächst beibehalten Zugriffsrechte dürfen erweitert werden (z.b. public anstelle von protected) Zugriffsrechte nicht eingeschränkt werden Grund für diese Regel: Ersetzbarkeit Daher muss die Subklasse nach außen hin mindestens alles das zur Verfügung stellen, was auch ihr Vorfahr zur Verfügung stellt Beim Überschreiben darf der Zugriff daher nicht weiter eingeschränkt werden 35

36 Zugriffsrechte und Sichtbarkeit Zugriffskategorien beim Überschreiben private-elemente, die in Unterklassen neu definiert werden, dürfen eine beliebige Kategorie besitzen Grund: private-elemente sind außerhalb der definierenden Klasse nicht sichtbar Eine Subklasse sieht die Elemente nicht es ist, als ob es diese Elemente gar nicht gäbe 36

37 Zugriffsrechte und Sichtbarkeit Zugriffskategorien beim Überschreiben Methoden mit impliziter Zugriffskategorie können so bleiben oder als protected oder public überschrieben werden protected darf als public überschrieben werden public-methoden müssen public bleiben 37

38 Die Bedeutung der Zugriffsrechte Information Hiding (Parnas) Jedes Objekt enthält die Details seiner Realisierung Nach außen soll so wenig wie möglich von den Details der Realisierung sichtbar sein Vererbung bricht Kapselung Ein Erbe übernimmt die Implementierung seiner Vorfahren Führt eine Abhängigkeit zwischen Ahnen und Erben ein Regel: es ist sinnvoll, so viele Attribute und Methoden wie möglich mit dem Sichtbarkeitsmodifikator private zu deklarieren 38

39 Mehrfachvererbung Bisher: Vererbung = Objektmodellierung mittels hierarchischer Taxionomie Was passiert, wenn mehrere verschiedene Taxionomien verwendet werden sollen? Lebewesen Pflanzen Spielgefährte Säugetiere Haustier Hunde Katzen Haushund Lösung: Mit Mehrfachvererbung (Vielfachvererbung, Multiple Inheritance) kann eine Subklasse die Funktionalität mehrerer Basisklassen erben 39

40 Mehrfachvererbung Bei Mehrfachvererbung erben die Subklassen die Eigenschaften und Methoden aller Basisklassen Angesteller Studierender personalnr : String matrikelnr : String geburtsdatum : Date fachbereich : int gehalt() : int lerne() alter() : int HiWi Ein HiWi ist sowohl Angesteller als auch Studierender Erbt die Eigenschaften personalnr und geburtsdatum von Angestellter Erbt die Eigenschaften matrikelnr und fachbereich von Studierender Erbt die Methoden gehalt() und alter() von Angestellter Erbt die Methode lerne() von Studierender Ersetzbarkeit: Objekte der Klasse HiWi kann überall verwendet werden, wo Objekte der Klasse Angesteller oder der Klasse Studierender verwendet werden kann 40

41 Mehrfachvererbung Probleme bei Mehrfachvererbung Elemente mit gleichem Namen können in mehreren Basisklassen vorkommen Beispiel: Angestellter und Studierender sollen je um ein Attribut Name erweitert werden Angesteller personalnr : String geburtsdatum : Date name : String gehalt() : int alter() : int Studierender matrikelnr : String fachbereich : int name : String lerne() HiWi Welche Bedeutung hat HiWi.name??? 41

42 Mehrfachvererbung Probleme bei Mehrfachvererbung Sprachen mit Mehrfachvererbung bieten verschiedene Strategien 1. Mehrfache Kopie und explizite Basisklasse (z.b. C++) Die Subklasse erbt alle Elemente Die Elemente mit Konflikten werden über den Namen der Basisklasse unterschieden Beispiel: HiWi h = new HiWi(); h.angestellter::name = "Name"; h.studierender::name = "anderer Name"; Attribute mit gleichem Namen können verschiedene Werte haben 42

43 Mehrfachvererbung Probleme bei Mehrfachvererbung 2. Mehrfache Kopie und explizites Umbenennen (z.b. Eiffel) Die Subklasse erbt alle Elemente Bei Konflikten muss der Programmierer den problematischen Elementen neue Namen geben Beispiel (Java-ähnlich): class HiWi extends Angestellter, Studierender { } rename Angestellter.name -> aname; rename Studierender.name -> sname; Attribute erhalten neue Namen, können weiterhin unterschiedliche Werte enthalten Vorteil gegenüber 1 Vererbungshierarchie ist nicht nach außen sichtbar: kann geändert werden Information Hiding! 43

44 Mehrfachvererbung Probleme bei Mehrfachvererbung 3. Einfache Kopie (z.b. C++) Basisklassen haben ihrerseits eine gemeinsame Basisklasse Namen der Basisklasse werden mehrfach vererbt - Konflikt Die Elemente mit Konflikten werden vereinigt, es gibt nur ein Element Beispiel: HiWi erbt name sowohl von Angesteller als auch von Studierender Grund: beide erben von Person HiWi.name wird auf Person.name abgebildet, ist eindeutig Elegant, funktioniert aber nur bei derartigen Gabelungen Angesteller personalnr : String geburtsdatum : Date gehalt() : int alter() : int Person name : String HiWi Studierender matrikelnr : String fachbereich : int lerne() 44

45 Interfaces Mehrfachvererbung bringt Probleme, wenn ein Element mehrfach benannt vorkommen kann Besonders konfliktträchtig: Attribute kommen mehrfach vor Java unterstützt keine Mehrfachvererbung von Klassen mit Attributen Allerdings: mit Interfaces (Schnittstellen) kann man ähnliche Effekte erzielen 45

46 Interfaces Was sind Interfaces? definieren Dienstleistungen für andere Klassen, ohne die Implementierung der Dienstleistungen festzulegen stellen funktionale Abstraktionen bereit, d.h.: legen das Was fest, aber nicht das Wie nur das Äußere einer Klasse, das ein Nutzer (Client) wissen muss, nicht das Innere, das für Clients gemäß OOP ohnehin versteckt wird verhalten sich wie Klassen, die nur abstrakte Methoden enthalten Interfaces können von anderen Interfaces erben Zwischen Interfaces ist mehrfache Vererbung möglich UML Notation <<interface>> AnInterface amethod() 46

47 Interfaces EBNF Interface-Definition = ["public "] "interface " Interface-Name [Interface-Extension] "{" Interface-Body "}". Extension = "extends " Base-Interface {"," Base-Interface }. Interface-Body = { ["public "] Method-Header ";" }. 47

48 Interfaces Interfaces enthalten nur eine Schnittstellenbeschreibung Namenskonflikt zwischen Methoden von Interfaces implementierte Methode gilt alle deklarierenden Interfaces Beispiel public interface AInterface { public void methoda(); public void methodx(); } public interface BInterface { public void methodb(); public void methodx(); } 48

49 Beispiel (fortgesetzt) Interfaces public interface ABInterface extends AInterface, BInterface { } // enthält Methoden: // void methoda() von AInterface // void methodb() von BInterface // void methodx() von AInterface und BInterface 49

50 Interfaces Implementierung von Interfaces Interfaces werden von Java-Klassen implementiert Wenn eine Klasse eine Schnittstelle implementiert, dann muss sie alle Methoden der Schnittstelle implementieren Ansonsten ist Klasse abstrakt, Unterklassen müssen fehlende Methoden implementieren Auch leere Implementierungen sind erlaubt, z.b. durch {} 50

51 Interfaces Implementierung von Interfaces - Notation Java: Interfaces werden nach dem implements Schlüsselwort in der Klassendefinition angegeben UML: Durch gestrichelte Linie des Vererbungspfeils <<interface>> AnInterface AnInterface wird implementiert von Klasse 1 Klasse1 Klasse2 AnInterface wird implementiert von Klasse 2 51

52 Verwendung von Interfaces Interfaces Verschiedene Java-Klassen können das selbe Interface auf unterschiedliche Weise implementieren Die Klienten-Klassen sprechen nur die entsprechenden Klassen nur über das Interface an Die implementierenden Klassen können nach Belieben verändert werden Die Schnittstelle des Interface bleibt unverändert keine Auswirkung auf Klienten-Klasse 52

53 Verwendung von Interfaces Interfaces Ein Interface kann wie eine abstrakte Klasse verwendet werden Variablen mit einem Interface als Typ sind möglich Verfügbare Methoden: alle im Interface deklarierten Methoden Prüfung, ob ein Objekt ein Interface implementiert: mit dem instanceof-operator anobject instanceof AnInterface anobject gehört zu einer Klasse, die AnInterface implementiert 53

54 Interfaces Beispiel Das Interface Comparable stellt eine Methode zur Verfügung, um zwei Objekte zu vergleichen compareto nimmt einen Parameter vom Typ Object und gibt zurück -1 oder kleiner wenn das implementierende Objekt kleiner als der Parameter ist 0 wenn das implementierende Objekt gleich zum Parameter ist +1 oder größer wenn das implementierende Objekt größer als der Parameter ist 54

55 Interfaces Beispiel Definition des Interfaces Comparable aus dem Java-Quelltext /* This interface imposes a total ordering on * the objects * of each class that implements * it. */ package java.lang; public interface Comparable { /* Compares this object with the specified * object for order. Returns a negative integer, * zero, or a positive integer as this object * is less than, equal to, or greater than the * specified object. */ int compareto(object o); } 55

56 Interfaces Beispiel Verwendung von Comparable in einer allgemeinen Methode, die Elemente in eine Liste sortiert einfügt Beispiel verwendet Klasse java.util.list Enthält mehrere beliebige Objekte Objekte werden über Index angegeben Index beginnt bei 0 56

57 Interfaces Beispiel java.util.list bietet Methoden int size() // gibt die Anzahl der Elemente in der Liste zurück Object get(int index); // liefert Objekt mit dem Index, der dem Parameter entspricht Beispiel: get(1) liefert Objekt B Objekt A Objekt B Objekt C Index 0 Index 1 void add(int index, Object element); // fügt element am angegebenen Index ein // alle nachfolgenden Elemente werden nach hinten geschoben 57

58 import java.util.list; Interfaces Beispiel /** * Neue Klasse SortedList, die sortiert einfuegt */ public class SortedList { private List elements = new List(); // leere Liste /** * Fuegt ein neues Element an die passende Position hinzu newelement das hinzuzufuegende Element, * darf nicht null sein */ public void add(comparable newelement) { if (newelement == null) return; // tue nichts, wenn newelement null ist int index = 0; boolean stored = false; // true, sobald newelement gespeichert ist 58

59 Interfaces Beispiel while (index < elements.size() &&!stored) { Comparable testelement = (Comparable)elements.get(index); // Cast noetig, da get nur ein Object liefert // wir wissen: alle Elemente sind comparable // (es werden keine anderen hineingesteckt) } // das Element am Index ist groesser als das // neue Element => Element auf diesen Index speichern if (testelement.compareto(newelement) > 0) { elements.add(index, newelement); stored = true; } index++; 59

60 Interfaces Beispiel if (!stored) // nicht gespeichert <=> newelement ist // groesser als alle Eintraege von elements // => speichern am Ende elements.add(elements.size(), newelement); } // end add /** * Gibt das Objekt am passenden Index zurueck */ public Object get(int index) { return elements.get(index); } } 60

61 Interfaces Beispiel public class Employee implements Comparable { String lastname; String firstname; /** Employees werden nach Namen geordnet */ public int compareto(object obj) { if (obj instanceof Employee) { Employee empl = (Employee)obj; int c = lastname.compareto(empl.lastname); // Strings enthalten bereits compareto } // Wenn Nachnamen gleich, entscheidet der Vorname if (c == 0) return firstname.compareto(empl.firstname); else return c; } else return -1 ; }... 61

62 Interfaces Beispiel public class Point extends GraphicObject implements Comparable { double x, y ; /** Points werden nach Abstand vom Ursprung geordnet */ public int compareto(object obj) { if (obj instanceof Point) { Point p = (Point)obj; double dist = x*x + y*y; double pdist = p.x*p.x + p.y*p.y; } if (dist == pdist) return 0; else return dist < pdist? -1 : 1; } else return -1 ; }... 62

63 Interfaces Beispiel SortedList kann sowohl Objekte vom Typ Point als auch Objekte vom Typ Employee sortiert speichern Änderungen am Quelltext der Klasse sind nicht notwendig Point kann weiterhin ohne Probleme von GraphicObject erben 63