Java Collection Framework

Transkript

1 Java Collection Framework Java-Standard-Bibliothek zahlreicher Datencontainer Alle gängigen Datenstrukturen zur Verfügung Trennung von Schnittstellen (IF / ADTs) und Implementierungen Verwendung von Generics Typsicher, keine Typ-Vermischungen, keine Downcasts Ziel ist nur ordnender Überblick - keine Auflistung aller Klassen Nicht alles wird besprochen - Rest dient als Wissensspeicher / Lese-Übung Alle Details : M.Naftalin, P.Wadler, "Java Generics and Collections", O'Reilly, 2007 Einige Abbildungen + Inhalte wurden dem Skript von Prof. Dr. Deck entnommen (67)

2 Java Collection Framework Grundsätzlicher Aufbau Einführende Beispiele (68)

3 Java Collection Framework Bibliothek zur Verwaltung verschiedener Sammlungen = Collections von Objekten Collection : Oberbegriff für Sammlung, Gruppe, Menge, Liste Alles im Paket java.util Framework besteht aus : Interfaces Hierarchie von Abstrakten Datentypen ADTs Implementierungen Hierarchie von Klassen - teils abstrakt, teils konkret verschiedene Implementierungen abstrakter Datentypen - z.b. ArrayList / LinkedList Algorithmen Implementierte Algorithmen für typische Operationen auf Collections (z.b. Suchen und Sortieren) Zwei grundsätzliche ADTs : Collection und Map (69)

4 Java Collection Framework - Interface-Hierachie M.Naftalin, P.Wadler "Java Generics and Collections", O'Reilly, 2007 Alle Collections sind iterabel Maps nicht (nicht direkt) (70)

5 Java Collection Framework - Anforderungen Verwender der Datenbehälter muss (praktisch immer) für seine Klassen eine erforderliche Infrastruktur implementieren Denn: Andernfalls werden Objekte nicht sicher / nicht konsistent verwaltet Anforderungen an Klassen-Infrastruktur : Sinn der Maßnahme equals( ) : hashcode( ) : compareto( ) : tostring( ) : Prüfung, ob Collection ein bestimmtes Element schon enthält Verwendung bei Collections auf Basis von Hash Tables Verwendung bei geordneten Collections zum korrekten Einsortieren Ausgabe des Inhalts einer Collection (71)

6 Java Collection Framework - Eingangsbeispiele import java.util.*; class Collection01 { // raw-type Variante public static void main( String[ ] args ) { Beispiel 1 : Datenbehälter nutzen Implementierungen setzen IF Collection um und erlauben Speichern beliebiger Objekte Collection c ; // IF-Collection : ADT c = new ArrayList( ) ; // ArrayList : eine konkrete Implementierung // alternativ : new LinkedList( ) / new HashSet( ) c.add( new Integer(8) ) ; // Hinzufügen von Elementen c.add( new Integer(2) ) ; Verwendung alternativer Implementierungen unterscheidet sich in Semantik z.b. keine Akzeptanz von Duplikaten in HashSet c.add( new Integer(9) ) ; c.add( new Integer(2) ) ; c.add( "Hallo" ) ; Integer i = new Integer(8) ; System.out.println( c.contains( i ) ) ; System.out.println( c ) ; // impliziter Aufruf : tostring( ) Vorsicht : add() kopiert Referenz aufs Orginal Man ist selbst für Kopie zuständig! contains() arbeitet intern mittels equals() die Objekte sollten equals() + hashcode() implementieren sonst wird nur Identität geprüft - nicht Äquivalenz! (72)

7 Java Collection Framework - Eingangsbeispiele import java.util.*; class GenericCollection01 { public static void main( String[ ] args ) { Beispiel 1 : Generischen Datenbehälter nutzen Collection<Integer> c = new ArrayList<Integer>( ) ; c.add( new Integer(8) ) ; // Hinzufügen von Elementen c.add( new Integer(2) ) ; c.add( new Integer(9) ) ; c.add( new Integer(2) ) ; c.add( "Hallo" ) ; // Compiler prüft Typfehler! Integer i = new Integer(8) ; Dank Generics herrscht Typsicherheit es lassen sich beliebige Objekte eines vorgegebenen Typs ablegen und einheitlich behandeln Nicht passende Typen werden vom Compiler abgewiesen System.out.println( c.contains( i ) ) ; System.out.println( c ) ; // impliziter Aufruf : tostring( ) Datenbehälter des Collection Frameworks verlangen nicht, dass die übergebenen Objekte Cloneable sind Deshalb wird auch stets die Referenz übernommen - und keine Kopie erstellt Wichtiges Detail : null-werte werden als Datenelemente akzeptiert und führen zur Erhöhung der internen size Docu im Detail konsultieren! (73)

8 Java Collection Framework - Eingangsbeispiele import java.util.*; class Collection02 { // nicht generisch public static void main( String[ ] args ) { Beispiel 2 : Sortieren einer Liste List c ; // ADT Subtyp von Collection c = new ArrayList( ) ; // Implementierung // alternativ : new LinkedList( ) c.add( new Mitarbeiter( 13, "Hans" ) ) ; Konkrete Implementierungen werden durch Tool-Klasse Collections unterstützt. c.add( new Mitarbeiter( 10, "Udo" ) ) ; c.add( new Mitarbeiter( 11, "Inge" ) ) ; Enthält nützliche Algorithmen in Form statischer Methoden. System.out.println( c ) ; // Ausgabe Collections.sort( c ) ; // Sortieren Kriterium auf nächster Folie System.out.println( c ) ; // Ausgabe (74)

9 Java Collection Framework - Eingangsbeispiele class Mitarbeiter implements Comparable { private int persnr ; private String name ; public Mitarbeiter(int persnr, String name ) { this.persnr = persnr ; this.name = name ; public String tostring( ) { return persnr + "," + name ; Beispiel 2 : Sortieren einer Liste Festlegung des Sortierkriteriums für die betreffenden Objekte durch Implementieren des IFs Comparable Methode sort( ) der Tool-Klasse arbeitet mit Comparable-Objekten public int compareto( Object o ) { Mitarbeiter m = (Mitarbeiter) o ; Bei Verwendung Raw-Type ist Cast zu Mitarbeiter erforderlich return this.persnr - m.persnr ; Wenn Mitarbeiter nicht Comparable implementiert, dann Compilerfehler bei Collections.sort( ) (75)

10 Java Collection Framework - Eingangsbeispiele import java.util.*; class GenericCollection02 { public static void main( String[] args ) { List<Mitarbeiter> c = new ArrayList<Mitarbeiter>( ) ; c.add( new Mitarbeiter( 13, "Hans" ) ) ; c.add( new Mitarbeiter( 10, "Udo" ) ) ; c.add( new Mitarbeiter( 11, "Inge" ) ) ; Beispiel 2 : Generisches Verwenden und Sortieren einer Liste Vergleichsmethode kann sich nun direkt auf Typ Mitarbeiter beziehen, so dass Downcasten entfällt! System.out.println( c ) ; Collections.sort( c ) ; System.out.println( c ) ; class Mitarbeiter implements Comparable<Mitarbeiter> { private int persnr ; private String name ; public Mitarbeiter( int persnr, String name ) { this.persnr = persnr ; this.name = name ; public String tostring( ) { return persnr + "," + name ; public int compareto( Mitarbeiter m ) { return this.persnr - m.persnr ; (76)

11 Java Collection Framework Designprinzip + Architektur Darstellung an fiktivem Beispiel (77)

12 Java Collection Framework - Prinzipieller Aufbau Zusammenspiel von Interface - abstrakten Klassen - konkreten Klassen Selbst definiertes fiktives Beispiel : SimpleListCollection Interface SList gibt Schnittstelle + Semantik vor ADT abstrakte Klasse AbstractSList stellt teilweise Implementierung zur Verfügung konkrete Klassen LinkedSList + ArraySList alternative komplette Implementierungen Man kann die fertigen konkreten Implementierungen benutzen kann sich aber auch auf die abstrakte Teilimplementierung beziehen und diese durch Überschreiben selbst konkretisieren oder das gesamte Interface selbst implememtieren! AbstractSList SList Interface abstrakte Klasse konkrete Klasse ArraySList LinkedSList Anmerkung : SList ist ein selbstentworfenes fiktives Beipiel, ist nicht (!) Teil des Collection Frameworks dort finden sich jedoch analoge Verhätnisse (78)

13 Java Collection Framework - Nomenklatur AbstractSList SList Interface abstrakte Klasse Abstrakter Datentyp konkrete Klasse ArraySList LinkedSList Art der Implementierung Unterschiedliche Techniken Direkt nutzbar interface SList { /*... */ // ADT abstract class AbstractSList implements SList { /*... */ Diese Art der Namens-Bildung wird im realen Collection Framework durchgehend verwendet class ArraySList extends AbstractSList { /*... */ class LinkedSList extends AbstractSList { /*... */ (79)

14 Java Collection Framework - Fiktives Bsp SimpleListCollection public interface SList { // einige Methoden... public boolean add( Object o ) ; // Hinzufügen eines Elements public int size( ) ; // Anzahl Elemente public Object get( int pos ) ; // Element an Position pos public boolean contains( Object o ) ; // Element enthalten? public boolean remove( Object o ) ; // Löschen eines Elements public boolean addall( SList ls ) ; // Hinzufügen aller Elemente einer SList public interface SList<E> { public boolean add( E o ) ; public int size( ) ; public E get( int pos ) ; public boolean contains( E o ) ; public boolean remove( E o ) ; public boolean addall( SList<E> ls ) ; Vorgaben des Interfaces Semantik des ADT : addall( SList ls ) Hinzufügen aller Elemente einer SList = Instanz einer beliebigen SList-Implementierung add( ) addall( ) remove( ) Rückgabewert true, falls sich Inhalt ändert Nicht im Interface spezifiziert Anforderungen an Konstruktoren Können null-werte zurückgeliefert werden? Zurückliefern von null sollte bedeuten, dass gesuchtes Elemente nicht vorhanden ist! Tatsächliche Unterstützung von Methoden - hier : remove( ) (80)

15 Java Collection Framework - Bsp SimpleListCollection public abstract class AbstractSList implements SList { public abstract int size( ) ; public abstract Object get( int pos ) ; public abstract boolean add( Object o ) ; public boolean contains( Object o ) { if( o == null ) return false ; for( int i=0; i<size( ); i++ ) { if( get(i).equals( o ) ) return true ; return false ; public boolean addall( SList slt ) { /*... */ public boolean remove( Object o ) { throw new UnsupportedOperationException( ) ; public String tostring( ) { StringBuffer sb = new StringBuffer( "[" ) ; for( int i=0; i<size(); i++ ) { sb.append( get(i) ) ; sb.append( ",") ; return sb.append( "]" ).tostring() ; Diese Methoden bleiben abstrakt Typischer Aufbau einer abstrakten Teilimplementierung AbstractSList Diese Methoden werden implementiert teilweise unter Rückgriff auf die noch abstrakten Methoden! Anmerkung : Wie beim original CF arbeitet auch hier contains() intern mittels equals() Gespeicherte Objekte sollten equals() und hashcode() überschreiben, damit contains() bei Äquivalenz true liefert. (81)

16 Java Collection Framework - Bsp SimpleListCollection Erläuterung zur Abstrakten Teilimplementierung von SList - Kriterien : Methoden get( ) size( ) add( ) : Sie können erst in konkreter Implementierung umgesetzt werden da von zugrundeliegender technischer Struktur abhängig Sieht anders aus für arraybasierte oder listenbasierte Umsetzung Werden erst in implementierender Klasse konkret überschrieben Einige Methoden können in abstrakter Klasse jedoch schon durch andere formuliert werden. Folgende Methoden lassen sich schon in abstrakter Klasse konkret formulieren durch Rückgriff auf die abstrakten Methoden : tostring( ) Iterieren über SList und Abgriff der Daten durch Methode get() contains( Object o ) Iterieren über SList und equals()-vergleich mit Object o addall( SList slt ) Iterieren über slt und Aufruf von add( slt.get(i) ) Anmerkung : Grundlegender Mechanismus ist Inversion of Control (82)

17 Java Collection Framework - Bsp SimpleListCollection public class LinkedSList extends AbstractSList { public boolean add( Object o ) {... public Object get( int pos ) {... Einfachere Ausimplementierung in konkreten Unterklassen LinkedSList und ArraySList : public int size( ) {... nächste Seite Nur noch drei abstrakte Methoden müssen implementiert / überschrieben werden nicht alle Methoden des Interfaces. public class ArraySList extends AbstractSList { public boolean add( Object o ) {... public Object get( int pos ) {... public int size( ) {... Teil der Arbeit wurde schon in abstrakter Klasse geleistet. Auch andere / weitere Implementierungen könnten analog auf der abstrakten Klasse aufbauen Weitere Optionen : Implementierung von Konstruktoren Implementierung von wirksamer Methode remove() durch Überschreiben Überschreiben von Methodendefinitionen der abstrakten Klasse zur weiteren Anpassung (83)

18 Java Collection Framework - Bsp SimpleListCollection public class LinkedSList extends AbstractSList { private Node head = null ; private int size = 0 ; public boolean add( Object o ) { // vorne einfügen if( o==null ) return false ; head = new Node( o, head ) ; size++ ; return true; public Object get( int pos ) { Es werden keine null-werte als Datenelemente akzeptiert! if ( pos < 0 pos >= size ) throw new IndexOutOfBoundsException( ) ; Node p = head ; for( int i=0; i<pos; i++ ) p = p.next ; return p.val ; public int size( ) { return size ; private class Node { // inner class public Object val ; public Node next ; public Node( Object o, Node next ) { val = o ; this.next = next ; Konkrete Ausimplementierung in der Klasse LinkedSList Anmerkung : Wie beim echten CF erstellt add() selbst keine Kopie des Original-Objekts, sondern weist die übergebene Referenz zu! (betrifft auch Methode addall() ) Es wird nicht vorausgesetzt, dass die übergebenen Objekte vom Typ Cloneable sind (84)

19 Java Collection Framework - Bsp SimpleListCollection - Generics public interface SList<E> { public boolean add( E o ) ; public int size( ) ; public abstract class AbstractSList<E> implements SList<E> { public abstract int size( ); public abstract E get( int pos ); public abstract boolean add( E o ); public E get( int pos ) ; public boolean contains( E o ) ; public boolean remove( E o ) ; public boolean addall( SList<E> ls ) ; Klassenhierarchie in generischer Form public boolean contains( E o ) { if( o==null ) return false ; for( int i = 0; i < size(); i++ ) { if ( get(i).equals( o ) ) return true ; return false ; public boolean addall( SList<E> slt ) { for( int i = 0; i < slt.size(); i++ ) { add( slt.get(i) ); return true; public boolean remove( E o ) { throw new UnsupportedOperationException( ); public String tostring( ) { StringBuffer sb = new StringBuffer("["); for( int i = 0; i < size(); i++ ) { sb.append( get(i) ); sb.append(","); return sb.append( "]" ).tostring( ) ; (85)

20 Java Collection Framework - Bsp SimpleListCollection - Generic public class LinkedSList<E> extends AbstractSList<E> { private Node head = null; private int size = 0; public boolean add( E o ) { if( o==null ) return false ; head = new Node( o, head ) ; size++; return true; public E get( int pos ) { Es werden keine null-werte als Datenelemente akzeptiert! Klassenhierarchie in generischer Form Konkrete Implementierung der LinkedSList<E> if( pos < 0 pos >= size ) throw new IndexOutOfBoundsException(); Node p = head; for( int i = 0; i < pos; i++ ) p = p.next; return p.val; Durch Überschreiben der drei abstrakt geerbten Methoden aus AbstractSList<E> public int size() { return size; private class Node { public E val ; public Node next; public Node( E o, Node next ) { val = o; this.next = next; (86)

21 Java Collection Framework Aufbau des realen Collection Frameworks : Zentrale Interfaces Abstrakte Teilimplementierungen (87)

22 Java Collection Framework - Aufbau Paket java.util Zahlreiche konkrete Implementierungen Hier nur die zentrale Auswahl JDK-Docu!! Entwickler kann & sollte sich geeignete Implementierung aussuchen z.b. : Array-basiert (schneller Read) versus LinkedList-basiert (schneller Insert) Aufbau Interfaces Nur Objekte als Datenelemente zugelassen, keine primitiven Typen Wrappen bzw. AutoBoxing abstrakte Klassen konkrete Implementierungen Algorithmen (Suchen & Sortieren) Collection-Klassen sind iterierbar Datenbehälter aus Performance-Gründen nicht synchronisiert = nicht-threadsicher! Threadsichere Behälter in java.util.concurrent (88)

23 Java Collection Framework - Aufbau Zwei unabhängige IF-Hierarchien + Basisdatentypen ADTs Collection wesentliche Eigenschaften - jedoch Vorgabe der Sammelstrategie erst durch folgende IFs : List positionsorientierte Sammlung von Objekten (Sequenz / Reihung) - Duplikate erlaubt! Lineare Einfügereihenfolge erhalten, positioniertes Auslesen / Einfügen via Index Set mengenorientierte Sammlung von Objekten - ohne Duplikate / keine Einfügetreue! als SortedSet in aufsteigend geordneter Form Queue als Deque mit beidseitiger Einfüge- und Entnahme-Semantik (s.u.) Map Jedem eindeutigen Schlüssel ist ein Wert zugeordnet Key-Value-Paar - Semantik SortedMap : intern nach Schlüssel sortiert (89)

24 Java Collection Framework - Collection Ausschnitt AbstractCollection Collection AbstractQueue Queue AbstractList List AbstractSet Set AbstractSequentialList HashSet ArrayList LinkedList TreeSet SortedSet Implementierungen auf Basis von Arrays, verketteten Listen, Hashtables, Bäumen Vorteil Array : Schneller direkter Zugriff auf Positionen - wenn Einfügen meist am Ende Vorteil LinkedList : Einfügen an beliebigen Positionen - wenn positioniertes Lesen selten Vorteil TreeSet : Aufsteigende Sortierung erstellt - und so auch iteriert durch Iterator Spezialisierungen : NavigableSet, LinkedHashSet, EnumSet... Queue, Deque, ArrayDeque, PriorityQueue... (90)

25 Java Collection Framework Collections : Lists und Sets (91)

26 Java Collection Framework - IF Collection Nur einige Methoden der Basis-Interfaces public interface Collection<E> extends Iterable<E> { public boolean add( E e ) ; // Hinzufügen eines Elements Erfolgsfall true public int size() ; // Anzahl der Elemente public void clear() ; // löscht alle Elemente public boolean contains( Object e ) ; // ist Element e enthalten? public boolean isempty() ; // ist Collection leer? public boolean remove( Object e ) ; // Löscht erstes(!) vorkommendes Elements e public Iterator<E> iterator( ) ; // liefert Iterator public boolean removeall( Collection<?> c ) ; // Löscht alle Elemente der Collection c aus Collection public boolean addall( Collection<? extends E> c ) ; // Hinzufügen aller Elemente der Collection c of E //... Semantik : add() addall() remove() Rückgabe true, falls Collection geändert - null akzeptiert! (92)

27 Java Collection Framework - IF List und Set public interface List<E> extends Collection<E> { public void add( int pos, E e ) ; // fügt Element e an Position pos ein, indiziert ab 0 public E get( int pos ) ; // Element an Position pos public int indexof( Object e ) ; // Index ersten Vorkommens des Elements e public E remove( int pos ) ; // entfernt Element an Position pos + gibt es zurück public E set( int pos, E e ) ; // ersetzt Element an pos durch e und gibt es zurück add() get() set() remove() IndexOutOfBoundsException bei nicht vorhandener Position add( E e ) : Einfügen am Ende remove( E e ) : Erstes Element e mit kleinstem Index Interface Set<E> hat gleiche (!) Schnittstelle wie Collection Aber mit Semantik nicht zugelassener Duplikate bei add-operationen! Reihenfolge der Elemente nicht spezifiziert nicht linear einfügetreu! Erst durch spezielle Implementierung gemäß Doku des Interfaces ergibt sich somit ein Verhalten, das sich von Listen unterscheidet Erst Interface SortedSet<E> fügt Methoden wie first(), last() etc. hinzu (93)

28 Java Collection Framework - Implementierungen Interfaces stellen an einzufügende Objekte keine speziellen Anforderungen : Es wird nicht gefordert, dass übergebene Objekte das IF Cloneable implementieren Die Methoden kopieren die Referenz aufs Orginal-Objekt man ist selbst für defensive copy zuständig! Falls man nur Objekt-Kopie an Datenbehälter übergeben will, benötigt Klasse clone() - Methode! import java.util.* ; class CopyTest { public static void main( String[] args ){ Collection<Mitarbeiter> c = new ArrayList<Mitarbeiter>( ) ; Mitarbeiter m1 = new Mitarbeiter(4711) ; c.add( m1 ) ; // Referenz auf Original in ArrayList c.add( m1.clone( ) ) ; // Nur Kopie class Mitarbeiter implements Cloneable { private int id ; public Mitarbeiter( int n ) { id = n ; public Mitarbeiter clone( ) { Mitarbeiter m = null ; try { m = (Mitarbeiter) super.clone( ) ; catch( CloneNotSupportedException e ) { return m ; //... (94)

29 Java Collection Framework - Implementierungen Methode contains() und andere verwenden für Objektvergleiche deren Methode equals( ) Aufgenommene Objekte sollten equals() + hashcode() konsistent überschreiben sonst wird stets nur Identität festgestellt (gemäß equals-implementierung von Object) - nicht Äquivalenz! import java.util.* ; class ContainsTest { public static void main( String[] args ){ Collection<Mitarbeiter> c = new ArrayList<Mitarbeiter>( ) ; Mitarbeiter m1 = new Mitarbeiter(4711) ; Mitarbeiter m2 = new Mitarbeiter(4711) ; c.add( m1 ) ; boolean check = c.contains( m2 ) ; class Mitarbeiter { private int id ; public Mitarbeiter( int n ) { id = n ; public boolean equals( Object o ) { if( this == o ) return true ; if( o==null this.getclass()!= o.getclass() ) return false ; Mitarbeiter m = (Mitarbeiter) o ; return this.id == m.id ; public int hashcode( ) { return id ; contains() liefert false, wenn Klasse Mitarbeiter equals() nicht überschreibt Dagegen true mit nebenstehender equals( ) - Implementierung! (95)

30 Java Collection Framework - List-Implementierungen Klassen ArrayList<E> und LinkedList<E> : Haben u.a. Konstruktoren, denen bereits gefüllte Collection-Datenstruktur übergeben werden kann, deren Elemente dann übernommen werden Bsp : ArrayList<E>( Collection<? extends E> ) ArrayList : Array-basierte Implementierung Diverse Konstruktoren - u.a. mit Vorgabe der anfänglichen Array-Länge Wenn Anfangslänge überschritten wird, findet automatische Vergrößerung statt ( = Anlegen neues Array + Kopieren der Elemente) LinkedList : Verkettete Liste mit Funktion einer doppelt verketteten Liste : Der zugehörige ListIterator kann in beiden Richtungen durch Liste navigieren Zugriff auf Element mit Index erfolgt vom Anfang oder Ende - je nachdem, was näher liegt Dient im CF auch zur Implementierung von Queues (96)

31 Java Collection Framework - Set-Implementierungen Sets lassen keine Duplikate zu. Hinzufügen Duplikat durch add() liefere false Konstruktor kann Collection übergeben werden Elemente übernommen + Duplikate eliminiert Methoden add() und addall() verwenden für Objektvergleiche deren Methode equals( ) Aufgenommene Objekte sollten equals() + hashcode() konsistent überschreiben sonst wird stets nur Identität abgewiesen - nicht aber Äquivalenz! import java.util.* ; class SetTest { public static void main( String[] args ) { Collection<Mitarbeiter> c = new HashSet<Mitarbeiter>( ) ; Aufruf add( m2 ) liefert true, wenn Klasse Mitarbeiter equals() nicht überschreibt. Dagegen false mit vorstehender equals() - Implementierung! Mitarbeiter m1 = new Mitarbeiter(4711) ; Mitarbeiter m2 = new Mitarbeiter(4711) ; boolean check1 = c.add( m1 ) ; boolean check2 = c.add( m2 ) ; Note : Übung - Warum? Great care must be exercised if mutable objects are used as set elements. The behavior of a set is not specified if the value of an object is changed in a manner that affects equals-comparisons while the object is an element in the set. (97)

32 Java Collection Framework - Set-Implementierungen HashSet<E> und TreeSet<E> Unterschiedliches Ordnungsverhalten : Objekte in HashSet müssen equals() + hashcode() überschreiben - für internen Objektvergleich. Es liegt keine Sortierung vor. Objekte in TreeSet müssen IF Comparable<T> implementieren - und somit Ordnung definieren. Objekte liegen aufsteigend geordnet. import java.util.* ; class HashSet01 { public static void main( String[] args ){ Set<String> s = new HashSet<String>( ) ; s.add( "IBM" ) ; s.add( "SAP" ) ; s.add( "Oracle" ) ; Iterator<String> it = s.iterator( ) ; while( it.hasnext() ) System.out.println( it.next() ) ; // "Chaotische" Ausgabe : SAP IBM Oracle import java.util.* ; class TreeSet01 { public static void main( String[] args ){ Set<String> s = new TreeSet<String>( ) ; s.add( "IBM" ) ; s.add( "SAP" ) ; s.add( "Oracle" ) ; Iterator<String> it = s.iterator( ) ; while( it.hasnext() ) System.out.println( it.next() ) ; // Sortierte Ausgabe : IBM Oracle SAP Alternative Konstruktoren mit Comparator-Übergabe (98)

33 Java Collection Framework - Set-Implementierungen LinkedHashSet<E> extends HashSet<E> Garantiert, dass Iterator die Elemente in der Reihenfolge zurück liefert, in der sie eingestellt wurden Intern wird dazu zusätzlich eine verkettete Liste der Set-Elemente verwaltet! Verbesserte Performance bei Iteration über alle Elemente via interner verketteter Liste Overhead zum Erstellen der zusätzlichen internen Struktur import java.util.* ; class LinkedHashSet01 { Prinzip Linked Hash Table : public static void main( String[] args ){ Set<String> s = new LinkedHashSet<String>( ) ; s.add("ibm") ; s.add("sap") ; SAP IBM s.add("oracle") ; Iterator<String> it = s.iterator(); while( it.hasnext( ) ) System.out.println( it.next( ) ) ; Oracle (start) // Ausgabe : IBM SAP Oracle (99)

34 Java Collection Framework Queues (100)

35 Java Collection Framework - Queue-Aufbau Ausschnitt AbstractQueue Queue PriorityQueue Einfügen gemäß Comparator! tail-position Deque double ended queue Deque erlaubt Queue-untypische Zugriffe durch Methoden wie offerlast() polllast() removelast() peeklast()... Symmetrisches Verhalten für Head + Tail Kann auch als Stack verwendet werden LinkedList ArrayDeque public interface Queue<E> extends Collection<E> { public boolean offer( E e ) ; // Hinzufügen Element // Exception bei leerer Queue : public E element( ) ; // Abfrage Head-Element ohne Entfernen Hinzufüge-Verhalten hängt von konkreter Implementerung ab - muss nicht Tail-Position sein.. public E remove( ) ; // Abfrage + Entfernen Head-Element // null bei leerer Queue : public E peek( ) ; // Abfrage Head-Element ohne Entfernen public E poll( ) ; // Abfrage + Entfernen Head-Element Viele weitere Spezialisierungen : Paket java.util.concurrent (101)

36 Java Collection Framework - Interfaces als Adapter Collection Ausschnitt aus Interface- / Typ-Hierachie, der von LinkedList implementiert wird List Queue Deque Interfaces als Adapter = Proxy-Pattern Klasse LinkedList implementiert alle in Interfaces geforderten Methoden Spezielles Verhalten durch Zuweisung von LinkedList-Objekt an Variable vom Typ des gewünschten Interfaces = ADT-Verhaltens LinkedList Collection c = new LinkedList( ) ; // Nur Methoden aus Collection z.vfg. List ls = new LinkedList( ) ; // Methoden + Verhalten von Liste Queue q = new LinkedList( ) ; // Methoden + Verhalten von Queue Deque dq = new LinkedList( ) ; // Methoden + Verhalten von Deque LinkedList kann je nach Anforderung vier verschiedene Rollen spielen, wovon aber jeweils nur eine gleichzeitig sinnvoll ist! Der Klient darf also nach der Wahl eines dieser Typen keinen Cast zu einem anderen Interface oder LinkedList selbst machen - da dann eine Melange aus Collection- List-Queue-Deque entsteht. (102)

37 Java Collection Framework - Queue-Implementierungen Einfüge- / Abgriffverhalten hängt von konkreter Implementierung ab : import java.util.* ; class QueueTest { public static void main( String[] args ) { Queue<Mitarbeiter> q ; q = new PriorityQueue<Mitarbeiter>( ) ; // *) for( int i=100; i>=0; i=i-10 ) q.offer( new Mitarbeiter( i ) ) ; // So nicht: for( Mitarbeiter m: q ) System.out.println( m ) ; // Sondern: Liefert Inhalt gemäß Mitarbeiter-ID: 0,10,20,... for( int i=0; i<=10; i++ ) System.out.println( q.poll( ) ) ; q = new ArrayDeque<Mitarbeiter>( ) ; for( int i=100; i>=0; i=i-10 ) q.offer(new Mitarbeiter( i ) ) ; // Liefert Inhalt gemäß FIFO: 100, 90, 80,... for( int i=0; i<=10; i++ ) System.out.println( q.poll( ) ) ; Wert von size() verändert sich durch poll() nicht im Schleifenkopf verwenden Anordnung bei PriorityQueue durch internen priority heap Direktes Iterieren liefert nicht gewünschte Prio-Folge Es muss gepollt werden Dies liefert least-first Reihenfolge gemäß Comparable-Verhalten der gespeicherten Objekte *) hier: Mitarbeiter ist Comparable! Wenn zu speichernde Objekte nicht Comparable sind, dann LZ-Exception (103)

38 Java Collection Framework - Collections sind iterable Alle Collection-Klassen implementieren generisch das Interface Iterable<T> import java.util.* ; class CollectionIteration { public static void main( String[ ] args ) { List<Mitarbeiter> ls = new ArrayList<Mitarbeiter>( ) ; ls.add( new Mitarbeiter( 13, "Hans" ) ) ; ls.add( new Mitarbeiter( 10, "Udo" ) ) ; ls.add( new Mitarbeiter( 11, "Inge" ) ) ; Iteratoren sind fail-fast : ConcurrentModificationException wenn Iterator merkt, dass seine Collection strukturell verändert wurde = Hinzufügen / Entfernen von Elementen Verhindert unkorrektes Weiterarbeiten des Iterators Iterator<Mitarbeiter> it = ls.iterator( ) ; while( it.hasnext( ) ) { Mitarbeiter m = it.next( ) ; // ls.add( new Mitarbeiter( 12, "Klaus") ) ; // Exception! for( Mitarbeiter m : ls ) System.out.println( m ) ; Einige Datenbehälter verfügen auch über Methode : Iterator<E> descendingiterator( ) liefert Reverse-Order-Iterator SnapShot-Iteratoren für spezielle Klassen wie CopyOnWriteArrayList (104)

39 Java Collection Framework Map ist kein Collection-Untertyp! Maps Assoziative Abbildungen Schlüssel-Wert-Verknüpfung / Dictionary Beispiel : Matrikelnummer = Schlüssel (einmaliger Key) Note = Wert (nicht einmaliger Value) (105)

40 Java Collection Framework - Map-Aufbau Ausschnitt AbstractMap Map key k1 k2 value v1 v2 Schlüssel (keys) sind eindeutig Sollten immutable sein! *) keys bilden ein Set! HashMap k3 v3 Zu jedem Schlüssel gehört ein Wert (value) Keys sind eindeutig - Values nicht TreeMap SortedMap Schlüssel-Wert-Semantik = Dictionary Kein Iterator - stattdessen : Weitere Spezialisierungen : NavigableMap, LinkedHashMap... Abgriff aller key-objekte als Set Abgriff aller Value-Objekte als Collection Anforderungen an Objekte : *) Note: Great care must be exercised if mutable objects are used as map keys. The behavior of a map is not specified if the value of an object is changed in a manner that affects equalscomparisons while the object is a key in the map. equals() + hashcode() implementieren! bei SortedMap zusätzlich IF Comparable! (106)

41 Java Collection Framework - IF Map public interface Map<K,V> { public V put( K key, V value) ; // Hinzufügen eines (k,v)-paares public V get( K key ) ; // Liefert Value für vorgegeben key - oder null public int size( ) ; // Anzahl der Paare Methode put() ersetzt bei bereits bestehendem key- Eintrag den alten Value durch neuen Value - und liefert alten Value zurück. public void clear( ) ; // löscht Inhalt public boolean containskey( Object k ) ; // Schlüssel k enthalten? public boolean containsvalue( Object v ) ; // Value v enthalten? public boolean isempty() ; // ist Map leer? public boolean remove( Object k ) ; // Löscht (k,v)-paar public Set<K> keyset( ) ; // liefert Set aller in Map enthaltener Key-Objekte public Collection<V> values( ) ; // liefert Collection aller in Map enthaltener Value-Objekte public void putall( Map<? extends K,? extends V> m ) ; // Hinzufügen aller Elemente der Map m public Set< Map.Entry<K,V> > entryset( ) // liefert alle (K,V)-Paare als Set, verpackt in Entry-Objekte public static interface Entry<K,V> // inneres Interface Map.Entry Collection-Views die von Orginal-Map geliefert werden "are backed by the map" An ihnen durchgeführte Veränderungen schlagen auf Orginal Map durch! (107)

42 Java Collection Framework - Map-Impl. HashMap import java.util.* ; class Registry { private HashMap<String,Object> registry = new HashMap<String, Object>( ) ; Registry-Pattern : Anwendungsbeispiel Objekte (value) können unter Namen (key) ein- und ausgetragen werden Durch Namensangabe erhält man Referenz auf registriertes Objekt public void bind( String name, Object obj ){ registry.put( name, obj ) ; public Object lookup( String name ) { Verwendung in Frameworks = Komponenten-Systeme Naming- / Lookup-Services return registry.get( name ) ; public void unbind( String name ) { registry.remove( name ) ; Konstruktoren HashMap HashMap( int initialcapacity ) HashMap( int initialcapacity, float loadfactor ) Bei Überschreiten loadfactor (= Anzahl Elemente / Anzahl Buckets) findet Rehashing statt = Kopieren in neue vergrößerte Hash-Table (108)

43 Java Collection Framework - IF SortedMap - Impl. TreeMap import java.util.* ; class TreeMapTest { public static void main( String[] args ){ SortedMap<String, String> m = new TreeMap<String, String>( ) ; m.put( "SBB", "Schweizerische Bundesbahn" ) ; IF SortedMap erweitert Map um Methoden wie firstkey(), lastkey() die auf interner Sortierung basieren m.put( "DB", "Deutsche Bahn" ) ; String s = m.put( "DB", "Deutsche Bahn AG" ) ; // s=deutsche Bahn System.out.println( m.get( "SBB" ) ) ; Anforderung konsistenter Klassen-Infrastruktur : HashMap : equals() + hashcode() Set<String> s = m.keyset( ) ; Iterator<String> it = s.iterator( ) ; while( it.hasnext( ) ) System.out.println( it.next( ) ) ; // alle keys als Set TreeMap : auch Comparable! Konstruktor von TreeMap kann Comparator übergeben werden Collection<String> c = m.values( ) ; // alle values als Collection Warum unterschiedlicher Rückgabetyp? (109)

44 Java Collection Framework Überblick - Aufbau Performance Korrekt implementierte Klassen-Infrastruktur zur Verwendung innerhalb Collection Framework (110)

45 Java Collection Framework - Aufbau Überblick Implementierung Set List Queue Deque Map Hashtable HashSet HashMap Array ArrayList ArrayDeque Baum TreeSet ProrityQueue TreeMap Verkettete Liste LinkedList LinkedList NavigableSet LinkedHashS et EnumSet NavigableMap LinkedHashMap IdentityHashMap EnumMap Thread-sichere Behälter Paket java.util.concurrent und Unterpakete Generell : Alle Implementierungen passen sich intern dynamisch an erforderliche Größe an. Alle Implementierungen haben überladenen Copy-Konstruktor - dem bereits vorhandene Collection übergeben werden kann, um deren Elemente zu übernehmen. (111)

46 Java Collection Framework - Performance Überblick M.Naftalin, P.Wadler, "Java Generics and Collections", O'Reilly, 2007 (112)

47 Java Collection Framework - Konsistente Infrastruktur class Mitarbeiter implements Cloneable, Comparable<Mitarbeiter> { private int id ; private String name ; public Mitarbeiter( int n, String nm ){ id = n ; name = nm ; public Mitarbeiter clone( ) { Mitarbeiter p = null ; try { p = (Mitarbeiter)super.clone( ) ; catch( CloneNotSupportedException e ) { return p ; public boolean equals( Object o ) { if( this==o ) return true ; if( o==null this.getclass()!=o.getclass() ) return false ; Mitarbeiter p = (Mitarbeiter) o ; return this.id == p.id ; public int hashcode() { return id ; public int compareto( Mitarbeiter p ) { return this.id - p.id ; public String tostring( ) { return id + "," + name ; //... Klassen, deren Objekte im Collection Frameworks aufgenommen werden, sollten die Java-Klassen- Infrastruktur konsistent implementieren zb. zwei Objekte, die equals sind, müssen auch gleichen hashcode liefern und bei compareto 0. alles andere führt zu Überraschungen / Fehlern Weitere Vergleichsmöglichkeiten durch zusätzliche Komparatoren Zum Versenden via Netz müssten Objekte Interface Serializable implementieren. (113)

48 Java Collection Framework java.util.collections : Algorithmen auf Collections Suchen & Sortieren Wrapper Speziell : Abgriff gespeicherter Datenelemente als Array (114)

49 Java Collection Framework - Collections-Algorithmen Statische Methoden der Klasse java.util.collections Ausschnitt Sortieren : void sort( List ls ) // Verwendung compareto( ) der Elemente void sort( List ls, Comparator cp ) // Verwendung compare( ) des Comparators cp Elemente der Liste müssen comparable sein - sonst Compiler-Fehler! Sortierkriterium : compareto( ) der Listelemente bzw. compare( ) von cp Stabiles Sortieren : Reihenfolge von Elementen wird nur wenn nötig geändert Binäre Suche in sortierter Liste : int binarysearch( List ls, E e ) int binarysearch( List ls, E e, Comparator cp ) // Angabe einer alternativen Sortierung durch cp Rückgabewert z 0 : Position des ersten Vorkommens von e Rückgabewert z < 0 : Nicht vorhanden Liste bliebe sortiert, wenn e an Position -(z+1) eingefügt würde Voraussetzung für verlässliche Resultate : Liste ist bzgl. compareto( ) bzw. cp.compare( ) aufsteigend sortiert! (115)

50 Java Collection Framework - Collections - Sortieren Beispiel : Sortieren einer List - nach mehreren Sortierkriterien Zugehörige Klasse Mitarbeiter umseitig import java.util.* ; class CollectionSort { public static void main( String[ ] args ) { List<Mitarbeiter> ls = new ArrayList<Mitarbeiter>( ) ; ls.add( new Mitarbeiter( 13, "Hans" ) ) ; Natürliche Ordnung durch compareto() erfasst ls.add( new Mitarbeiter( 10, "Udo" ) ) ; ls.add( new Mitarbeiter( 11, "Anne" ) ) ; Collections.sort( ls ) ; / / Sortieren nach compareto( ) System.out.println( ls ) ; Andere Ordnungen durch Comparator- Objekte zusätzlich zur Vfg. gestellt Collections.sort( ls, Mitarbeiter.NAME_COMP ) ; // Sortieren nach Name System.out.println( ls ) ; (116)

51 Java Collection Framework - Collections - Sortieren Sortieren einer List nach mehreren Sortierkriterien Klasse Mitarbeiter : comparabel nach persnr - und besitzt zusätzlichen Comparator Anm : Klassen können beliebig viele Comparatoren haben aber nur eine Methode compareto( ) Methoden equals() + hashcode() sollten in Einklang mit Methode compareto() arbeiten! class Mitarbeiter implements Comparable<Mitarbeiter> { public static Comparator NAME_COMP = new NameComparator( ) ; private int persnr ; private String name ; public Mitarbeiter( int persnr, String name ) { /*...*/ public String tostring( ) { /*...*/ public int compareto( Mitarbeiter m ) { return this.persnr - m.persnr ; private static class NameComparator implements Comparator<Mitarbeiter> { public int compare( Mitarbeiter m1, Mitarbeiter m2 ) { // bzgl. Name String s1 = m1.name ; String s2 = m2.name ; return s1.compareto( s2 ) ; //... (117)

52 Java Collection Framework - Collections Wrappers Statische Wrapper-Methoden liefern für bestehende Collection neue Wrapper-Objekte, die das Standard-Verhalten der Collection-Klassen verändern = Protection Proxy Pattern Reichen Methodenaufrufe an Orginal-Methoden durch - aber kontrollieren den Zugriff! Jeweils zusätzlich separate Methoden für die Haupt-Interfaces des Collection Frameworks (d.h. für : Set, List, Map, SortedSet, SortedMap) 1. Synchronized Collections <T> Collection<T> synchronizedcollection( Collection<T> c ) Liefern thread-sicheres synchronisiertes Collection-Objekt 2. Unmodifiable Collections <T> Collection<T> unmodifiablecollection( Collection<T> c ) Liefern Collection-Objekt, das bei jeder Strukturänderung UnsupportedOperationException wirft 3. Checked Collections <T> Collection<T> checkedcollection( Collection<T> c, Class<T> type ) Liefern Collection-Objekt, das bei jedem weiteren hinzugefügten Element testet, ob der vorgegebene Klassentyp eingehalten wird - auch wenn im nicht generischen Raw-Type-Coding verwendet Andernfalls wird ClassCastException geworfen (118)

53 Java Collection Framework - Abgriff Inhalte als Array Interface Collection : Object[ ] toarray( ) // kopiert Inhalt in Object-Array <T> T[ ] toarray( T[ ] t ) // kopiert Inhalt in typsicheres T[ ]-Array Collection<String> c = new LinkedList<String>( ) ; c.add("er") ; c.add("sie") ; c.add("es") ; String[ ] s1 = new String[0] ; // typisches Idiom - Länge 0 String[ ] s2 = new String[5] ; // dient wirklich zur Aufnahme // Übergebenes Array nicht groß genug // Neues exakt passendes Array typsicher angelegt + zurück geliefert : String[ ] s3 = c.<string>toarray( s1 ) ; // Übergebenes Array groß genug // In übergebenes Array typsicher kopiert + Referenz darauf zurück geliefert : Inhalte : s3 := [ er, sie, es ] s2 := [ er, sie, es, null, null ] c.<string>toarray( s2 ) ; (119)

54 Data Access Object - Pattern (DAO) Zugriff auf Datenquelle als SWE-Beispiel : Schichtenbildung + Abstraktion als typische Software-Engineering-Technik Wenn du es eilig hast dann nimm einen Umweg! Chinesisches Sprichwort Einige Abbildungen + Inhalte wurden dem Skript von Prof. Dr. Deck entnommen (124)

55 DAO Data Access Object Konkreter Datenzugriff hängt stets von Eigenarten der speziellen Datenquelle ab Relationale DB, NOSQL DB, XML, flache Datei, Herstellerabhängige SQL-Dialekte Ziel : Abstraktion + Entkopplung von Anwendungs- und Persistenzschicht Objekt-Relationales Mapping übersichtlich bewältigen Flexibilität hinsichtlich unterschiedlicher Persistenzimplementierungen komponentenbasiertes Design + modulare Entwicklung Präsentation Applikation Persistenz Menüführung Darstellung Eingabe Geschäftslogik Konsistenzprüfungen Datenaufbereitung DAO Datensicherung Datenabfrage Bsp : Verwaltung von Mitarbeitern (Objekten!) - benötigte Methoden für Datenzugriff : Anzeige einzelner Mitarbeiter CRUD Anzeige aller Mitarbeiter Neu-Anlegen eines Mitarbeiters Ändern eines Mitarbeiters Löschen eines Mitarbeiters (125)

56 DAO Java-Realisierung 1. Defintion eines DAO-Interfaces : Objektorientierte Formulierung - nicht relational und nicht DB-spezifisch! public interface MitDAO { // CRUD : public Mitarbeiter getmitbypnr( int persnr ) throws DAOException ; public List<Mitarbeiter> getallmit( ) throws DAOException ; public boolean insertmit( Mitarbeiter m ) throws DAOException ; //... Detail : Zwischenspeichern von Objekten in Liste Minimieren der DB-Zugriffe. Nicht jede DataAccess-Methode benötigt erneuten Zugriff auf echte Persistenz-Schicht! // Verallgemeinerung : Generisches DAO-IF public interface GenDAO<K,V> { public V get( K key ) ; public List<V> getall( ) ; public boolean insert( V val ) ; public boolean delete( K key ) ; public boolean update( K key, V val ) Bei Fehlersituationen spezielle Ausnahme auslösen evtl. eigene Klasse : DAOException extends Exception In Interface-Signatur Erlaubnis zum Werfen! (126)

57 DAO Java-Realisierung 2. Bereitstellen einer oder mehrerer Implementierungen : public class HSQLDBData implements MitDAO{ public class OracleData implements MitDAO{ public class FlatFileData implements MitDAO{ public class DummyData implements MitDAO{ public class EmptyData implements MitDAO { Speziell : Leere Implementierung zu Test- / Compilations-Zwecken public Mitarbeiter getmitbypnr( int pnr ) { return null ; public List<Mitarbeiter> getallmit( ) { return null ; public boolean insertmit( Mitarbeiter m ) { return true ; public boolean deletemit( int pnr ) { return true ; public boolean updatemit( int pnr, Mitarbeiter m ) { return true ; (127)

58 DAO Java-Realisierung 3. Anwendungsseitig Programmierung nur gegen das Interface : public static void main( String[ ] args ) { MitDAO data = new HSQLDBData( ) ; // * oder andere Impl.! //... private void alleanzeigen( ) { // Verwendung Interface-Typ data List<Mitarbeiter> mitlist = data.getallmit( ) ; //... an Oberfläche anzeigen private void loeschen( ) { int persnr ; // durch Anwendung persnr ermitteln data.deletemit( persnr ) ; private void neu( ) { // Mitarbeiterwerte ermitteln int persnr =... String name =... data.insertmit( new Mitarbeiter( persnr, name ) ) ; //... Konkrete Implementierung tritt nur an einer Stelle * in Erscheinung! Von konkreter Implementierung wird somit abstrahiert austauschbar! Rest der Anwendung bleibt völlig unverändert - auch wenn in * andere Implementierung eingesetzt wird. Abstraktion und Entkopplung von Anwendungs- und Persistenzschicht Flexibilität für unterschiedliche Persistenzimplementierungen. Reduktion Wartungsaufwand! Steigerung Wiederverwendbarkeit! Stärkung Modularität! Reduktion Komplexität! (128)

59 DAO Java-Realisierung - Vorteile Unterstützt modulare komponentenbasierte Entwicklung - Präsentation ( View ) - Applikation ( Model + Controller ) - Persistenzschicht Frühzeitiges Testen von Präsentation + Anwendung - auch ohne DB-Anschluss - leere DAO-Implementierung zum Compilieren + rudimentäre Ablauftests - temporäre Implementierung zum fast vollständigen Test der Anwendung Austausch der Implementierungen - Unterstützung unterschiedlicher RDBMS - Sauberes Objekt-Relationales Mapping - Unterstützung verschiedener Persistenz- und Datenbankmodelle Präsentation Applikation Persistenz persnr =... name =... Mitarbeiter m = new Mitarbeiter( p, name ) DAO data.insert(m) OK INSERT INTO MITARBEITER VALUES (129)

60 DAO Temporäre Ersatz-Realisierung Mock-Objekt class TempData implements MitDAO { private List<Mitarbeiter> mitliste ; public TempData( ) { // erzeugt Einträge mitliste = new ArrayList<Mitarbeiter>( ) ; mitliste.add( new Mitarbeiter( 2, "Hans" ) ) ; mitliste.add( new Mitarbeiter( 4, "Inge" ) ) ; public List<Mitarbeiter> getallmit( ) { return mitliste ; public Mitarbeiter getmitbypnr( int p ) { for( Mitarbeiter m : mitliste ) if( m.getpersnr() == p ) return m ; return null ; public boolean insertmit( Mitarbeiter m ) { if( mitliste.contains( m ) ) return false ; mitliste.add( m ) ; return true ; //... weitere Methoden Objekte werden in Liste verwaltet, aufgenommen, gelöscht, geändert Volle Funktionalität - solange Programm läuft Keine echte Persistenz Aber funktionsfähig - z.b. für Applikationstests Echte DB wird nicht "verschmutzt" Dummy-Objekt : Leere Implementierung der Schnittstelle ohne jede Funktionalität Mock-Objekt : Minimale Implementierung der Schnittstelle - oft mit konstanten Werten - aber ohne echte Persistenz (130)

61 DAO Echte JDBC-Realisierung class HSQLDBData implements MitDAO { private static String driver = "..." ; private static String url = "..." ; public HSQLDBData( ) { Class.forName( driver ) ; noch ohne Exception-Handling public List<Mitarbeiter> getallmit( ) { Connection con = DriverManager.getConnection( url ) ; List<Mitarbeiter> list = new LinkedList<Mitarbeiter>( ) ; Statement st = con.createstatement( ) ; ResultSet rs = st.executequery( "SELECT * FROM MITARBEITER" ) ; while( rs.next( ) ){ int persnr = rs.getint( "PERSNR" ) ; String name = rs.getstring( "NAME" ) ; Mitarbeiter m = new Mitarbeiter( persnr, name ) ; list.add( m ) ; if( con!=null ) { con.close( ) ; rs.close( ) ; st.close( ) ; return list ; //... weitere analog zu implementierende IF-Methoden... Objekt-Relationales- Mapping ORM Umsetzung relationales Modell in Java-Objekte Passiert in DAO-Implementierung Belastet nicht zentrales / restliches Applikations-Coding! (131)

62 DAO Realisierung in Java Minimieren der DB-Zugriffe Nicht jede DataAccess-Methode benötigt erneuten Zugriff auf Persistenz-Schicht Zwischenspeichern von Objekten in Liste, die von Applikationsschicht gehalten wird Präsentation anzeige() Applikation List<Mitarbeiter> list getallmit() Persistenz Details egal anzeige() andere Sortierung sort( list ) details(pnr) DAO aber konform zu Interface MitDAO neu() insertmit() Auch bei Verwendung einer echten DB macht DAO-Zwischenschicht mit ihren temporären Datenbehältern somit als Cache / Puffer / InMemory-Element Sinn (132)