OOP-4.1 4. Programmbausteine, Bibliotheken und Programmgerüste Konzept Programmbaustein: Programme aus vorgefertigten Teilen zusammensetzen - statt ganz neu schreiben "Baukasten", industrielle Produktion Gute Bausteine, Programmgerüste: geplante Wiederverwendung, kostbar, aufwändig Wichtige Fragen: * Wie stellt man gute Bausteine her? * Wie allgemein bzw. anpassbar sind die Bausteine? * Sind die Bausteine direkt einsetzbar oder realisieren sie nur Teilaspekte und müssen vor der Anwendung komplettiert werden? * Sind die Bausteine unabhängig voneinander oder wechselseitig aufeinander angewiesen? * Wie werden Bausteine zusammengesetzt? nach [Arnd Poetzsch-Heffter: Konzepte Objektorientierter Programmierung, Springer, 2000] (c) 2005 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 401 Ziele: Wiederverwendbare Bausteine in der Vorlesung: Begriffe erläutern nachlesen: Poetzsch-Heffter, Kap.4 -------------------------------------------------------------------------------- OOP-4.2 Beziehungen zwischen Programmbausteinen Unabhängige Bausteine Eigenständige Bausteine Eng kooperierende Bausteine Schnittstelle verwendet nur Bausteinfamilie ist Bausteinfamilie dient vom Baustein deklarierte hierarchisch strukturiert. komplexer, spezieller Typen oder Standardtypen Schnittstelle verwendet softwaretechnischer (Grundtypen und die aus zusätzlich Supertypen (oft Aufgabenstellung. java.lang). abstrakt) Enge Kooperation führt zu Beispiele: Beispiele: komplexen Abhängigkeiten, Datentypen z. B. verschränkt rekursiver - die Typen zur Beziehung von Typen und - Listen Ausnahmebehandlung in Methoden. - Mengen Java - Hashtabellen Beispiele: - die Stromklassen aus Programmgerüste, wie Typisch: java.io Elementanpassung durch * Java AWT generische Typparameter Typisch: Trotz der * San Francisco (IBM): (z. B. in C++: Leda, STL) hierarchischen Beziehung Abwicklung von Geschäfts- sind die Bausteine prozessen lokal verstehen, einfach eigenständig verwendbar. Typisch: wg. Abhängigkeiten isolierte Aufgaben keine Querbeziehungen, anspruchsvoller nur Abstraktion (c) 2005 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 402 Ziele: Klassifikation nach Abhängigkeit in der Vorlesung: Begriffe an Beispielen erläutern nachlesen: Poetzsch-Heffter, Kap.4 -------------------------------------------------------------------------------- OOP-4.3 Unterschied zwischen Progammgerüst und Bausteinbibliothek Bausteinbibliotheken * mit unabhängigen oder ADTs eigenständigen Bausteinen * anwendungsunabhängig Anwendung ... * Ablauf unter Kontrolle des Anwendungsprogramms Math Programmgerüst (Framework) * "fast-fertige" Anwendung Networking * anwendungsspezifisch G U * Umkehr der Ablaufsteuerung, Anwendung I call-back-Routinen, call-back "don't call us, we call you" Database ruft auf (c) 2013 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 403 Ziele: Anwendungsstrukturen in der Vorlesung: Erläuterung der beiden Strukturen und Beispiele. Abstufungen dazwischen: * unstrukturierte Aufrufebene, * Aufruf-Protokolle (Client/Server), * Zusammenstecken von Bausteinen mit verborgener Kommunikation, * komplexe Kommunikation im Programmgerüst. nachlesen: Poetzsch-Heffter, Kap.4 -------------------------------------------------------------------------------- OOP-4.4 Die Java-Bibliothek eigenständige Bausteine java applet awt beans io math net rmi security sql text util lang event font image ref reflection registry server zip jar Programmgerüst Framework unabhängige Bausteine (c) 2005 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 404 Ziele: Beispiel für Standardbibliotheken in der Vorlesung: Erläuterungen dazu * Anwendungsbereich einiger Pakete erläutern. * Strategie: kleine Sprache + große Bibliothek nachlesen: Poetzsch-Heffter, Kap.4 -------------------------------------------------------------------------------- OOP-4.5 Anwendung von Bausteinen: Ausnahmebehandlung in Java Ausnahmebehandlung als einfaches Beispiel für eine erweiterbare Bausteinhierarchie Zeigt das enge Zusammenspiel zwischen Sprache und Bibliothek Trend bei modernen OO-Sprachen: Anzahl der Sprachkonstrukte klein halten, mit Mitteln der Sprache formulierbare Konzepte in die Bibliothek; extrem: In Smalltalk sind ifTrue, IfFalse Methoden der Bibliotheksklasse Boolean Ausnahmebehandlung in Java: Bei "abrupter Terminierung" der Auswertung von Ausdrücken oder Ausführung von Anweisungen wird * ein Ausnahmeobjekt e erzeugt und * die in der dynamischen Umgebung (Laufzeitkeller) nächste, zur Klasse von e passende Ausnahmebehandlung mit e als Parameter aufgerufen. 3 Arten von Ausnahmen (siehe Klassifikation, OOP-4.7): * Benutzer hat kaum Einfluss darauf, z. B. erschöpfte Maschinenressourcen (Error), * vermeidbare Ausnahmen wegen Programmierfehlern, z. B. der Versuch, die null-Referenz zu dereferenzieren (RunTimeException), * nicht vermeidbare Ausnahmen, die im Ablauf des Programms vorgesehen sein sollten, z. B. Zugriff auf nicht vorhandene Eingabe-Datei (weitere Unterklassen von Exception) (c) 2013 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 405 Ziele: Beispiel für Bausteine im Sprachkontext in der Vorlesung: * Zusammenwirken von Sprache und Standard-Bibliothek, * Grundbegriffe der Ausnahmebehandlung, * Ausnahmearten erläutern. nachlesen: Poetzsch-Heffter, Kap.4 -------------------------------------------------------------------------------- OOP-4.7 Ausnahmehierarchie Object Throwable-Objekt enthält * Fehlermeldung * Methode, um den Kellerinhalt zu drucken Throwable Error Exception AbstractMethodError RunTimeException IOException OutOfMemoryError NullPointerException ClassNotFoundException StackOverflowError IndexOutOfBoundsException KeinKaffeeException public class KeinKaffeeException IllegalArgumentException extends Exception { private float restMenge; KeinKaffeeException NumberFormatException (float kaffeeMenge ) { restMenge = kaffeeMenge; } public float getRestMenge () Die Ausnahmeklassen definieren eigenständige { return restMenge; } Bausteine mit einer sehr einfachen Funktionalität. } (c) 2005 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 407 Ziele: Erweiterbare Bausteinhierarchie in der Vorlesung: Erläuterungen zu * der Hierarchie, * Beispielen von Ausnahmen, * Erweiterungen (über 100 in der Java Bibliothek) * den Ausnahmearten. nachlesen: Poetzsch-Heffter, Kap.4 -------------------------------------------------------------------------------- OOP-4.10 Kriterium für Entwurfsqualität: Kohärenz Kohärenz (Bindung): Stärke des funktionalen Zusammenhangs zwischen den Bestandteilen eines Bausteins Ziel: So stark wie möglich Kohärenz einer Klasse: starke Kohärenz weil Komponenten * Klasse realisiert nur ein semantisch funktional zusammenhängen bedeutungsvolles Konzept schwache oder keine Kohärenz * ihre Methoden kooperieren für weil Komponenten diese Aufgabe * Menge der Methoden ist vollständig zur gleichen Zeit gebraucht werden (z.B. Initialisierung) * keine Methode ist überflüssig für das Konzept in der Ablaufstruktur zusammenhängen zufällig zusammengekommen sind (c) 2013 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 410 Ziele: Strukturierungskriterium Kohärenz verstehen in der Vorlesung: Erläuterungen: * Kohärenz: ein einziges Konzept; alle Methoden arbeiten an dieser Aufgabe -------------------------------------------------------------------------------- OOP-4.10c Kriterien Entwurfsqualität: Kopplung Kopplung: Stärke der Beziehung, Interaktion zwischen Bausteinen * Kopplung zwischen Methoden, zwischen Klassen, zwischen Paketen * Kopplung entsteht durch Benutzen von Daten oder durch Aufrufe (siehe OOP-4.11) Ziel: Kopplung so schwach wie möglich * schwache Kopplung entspricht schmaler Schnittstelle dadurch bessere * Zerlegbarkeit * Komponierbarkeit * Verständlichkeit * Sicherheit (c) 2005 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 410c Ziele: Strukturierungskriterium Kopplung verstehen in der Vorlesung: Erläuterungen: * Kopplung auf gleicher Abstraktionsebene -------------------------------------------------------------------------------- OOP-4.11 Maßnahmen zur Entkopplung Unnötige Kopplung von Klassen vermindert grundlos die Wiederverwendbarkeit Anwendung von Vererbungsparadigmen: * Rollen und Eigenschaften: Material entkoppelt von Werkzeugen, Verhalten entkoppelt vom Subjekt * Spezifikation: Implementierung entkoppelt von Anwendungen Entwurfsmuster: * Bridge: verfeinerte Spezifikation entkoppelt von Implementierungen * Strategy: Implementierung entkoppelt von Anwendungen * Abstract Factory: konkrete Erzeuger der Objekte entkoppelt von Anwendungen * Observer: veränderliches Subjekt entkoppelt von Präsentatoren des Zustandes (c) 2013 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 411 Ziele: Entkopplung durch Vererbungsparadigmen und Entwurfsmuster in der Vorlesung: Erläuterungen dazu -------------------------------------------------------------------------------- OOP-4.13 Beispiel zur Entkopplung: Sortieren von Personen-Listen class Person SortedPersonList oop = { Name n; new SortedPersonList(); long PersNr; Person neu; ... ... } oop.add (neu); Was ist hieran schlecht? class SortedPersonList { Object[] elems; ... public void add (Person x) { ... Name a = x.getName(); Diese Klasse ist für nichts Name b = anderes zu gebrauchen! (Name)elems [k].getName(); if (a.lessThan(b)) nicht wiederverwendbar! ... ... } } (c) 2013 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 413 Ziele: Kopplungsbeispiel für nächste die Folie in der Vorlesung: Erläuterung des Beispiels -------------------------------------------------------------------------------- OOP-4.14 Entkoppeln durch Interfaces interface Comparable Schnittstelle { public boolean lessThan (Object compareMe); entkoppelt } Bausteine class Person implements Comparable { Name n; long PersNr; public boolean lessThan(Object compareMe) { return n.lessThan(((Person)compareMe).n); } } class SortedList { Object[] elems; ... wiederverwendbare public void add (Comparable x) Klasse! { if (x.lessThan(elems[k])) unabhängig von den ... sortierten Elementen ... } } (c) 2013 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 414 Ziele: Entkopplungsmethode: Schnittstellen in der Vorlesung: Erläuterungen dazu. Siehe auch in 2.4 Eigenschaftsklassen -------------------------------------------------------------------------------- OOP-4.15 Entkoppeln durch Funktoren Die Vergleichsfunktion wird erst bei Objekterzeugung bestimmt. Variable Funktionen werden in Objekte verpackt [Functor Pattern von Coplien] import java.util.Comparator; // seit Java 1.2 class Person {Name n; long PersNr; ...} class PersonComparator implements Comparator Funktor: { public int compare (Object links, Object rechts) Verpackung von { return Vergleichsfunk- ((Person)links).n.lessThan (((Person)rechts).n)? tion für Person- -1:((Person)links).n.equal (((Person)rechts).n)? Objekte 0 : 1; } } class SortedList { private Comparator cmp; ... wiederverwend- public SortedList (Comparator c) { cmp = c; } bar ... public void add (Object o) wird mit { ... leq = cmp.compare (o, elements[k]); ... Vergleichsfunk- } } tion initialisiert Vorsicht: Passt nicht zum Grundsatz "Klasse beschreibt Zustand und Verhalten". (c) 2013 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 415 Ziele: Variable Funktionen verwenden in der Vorlesung: Erläuterungen dazu * Technik: Funktionen in Objekte verpackt, * Wiederverwendbarkeit durch Initialisierung mit Funktion(sobjekt)en * Technik ist für Anfänger ungeeignet -------------------------------------------------------------------------------- Mod - 4.18 Objektorientierte Programmgerüste Programmgerüst (Framework): Integrierte Sammlung von Bausteinen, die zusammenarbeiten, um eine wiederverwendbare, erweiterbare Architektur für eine Familie verwandter Aufgaben zur Verfügung zu stellen. [siehe Folie 4.3] Charakteristika: * "fast-fertige" Anwendung Networking mit geplanten Erweiterungsstellen * anwendungsspezifisch G Anwendung U * Umkehr der Ablaufsteuerung, I call-back-Routinen, call-back "don't call us, we call you" Database * komplexe Beziehungen zwischen den Bausteinen werden ohne Zutun des Programmgerüst Benutzers wiederverwendet (c) 2013 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 418 Ziele: Wiederholung des Begriffes Programmgerüst in der Vorlesung: Verweis auf Folie OOP-4.3 nachlesen: Budd: Understanding OOP with Java, Abschnitt 4 -------------------------------------------------------------------------------- OOP -4.19 Entwicklung mit Programmgerüsten Die Anwendung * spezialisiert Klassen des Programmgerüstes, * füllt Erweiterungsstellen des Programmgerüstes aus: * implementiert call-back-Routinen, die vom Programmgerüst aufgerufen werden * implementiert Reaktionen auf Ereignisse, die über das Programmgerüst ausgelöst werden * setzt Algorithmen, Klassen, die das Programmgerüst anbietet, zu Schnittstellen ein, die das Programmgerüst vorgibt. (c) 2013 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 419 Ziele: Gegenüberstellung von Bibliotheken in der Vorlesung: * Kriterien erläutern und anwenden nachlesen: Budd: Understanding OOP with Java, Abschnitt 4 -------------------------------------------------------------------------------- OOP-4.20 Programmgerüst am Beispiel des Java AWT Was macht Java AWT zum typischen Beispiel für ein Programmgerüst? 1. Der Anwendungsbereich Benutzungsoberflächen ist komplex und vielfältig variierbar. 2. Java AWT deckt den Anwendungsbereich vollständig ab; man kann damit vollständige Benutzungsoberflächen entwickeln - nicht nur einzelne Teilaufgaben erledigen 3. Einzelne Komponenten des Java AWT sind spezialisierbar: bieten umfangreiche wiederverwendbare Funktionalität; Benutzer ergänzt sie durch vergleichsweise kleine spezifische Ausprägung; siehe Frame als Beispiel für das Konzept Spezialisierung (OOP-2.9) 4. komplexes Zusammenwirken der Komponenten liegt fast vollständig in der wiederverwendbaren Funktionalität. Voraussetzung: wohl-definierte Software-Architektur des Java AWT; siehe OOP-4.23 (c) 2013 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 420 Ziele: Typische Eigenschaften von Programmgerüsten am Beispiel in der Vorlesung: Erläuterungen zu * dem Anwendungbereich GUI, * dem Konzept Spezialisierung durch Erinnerung an OOP-2.9, 2.10, * dem komplexen Zusammenwirken werden auf OOP-4.23 fortgesetzt nachlesen: Poetzsch-Heffter, Kap. 5 -------------------------------------------------------------------------------- OOP-4.23 Komplexes Zusammenwirken im Programmgerüst Beispiele für komplexes Zusammenwirken der AWT-Komponenten: * Ereignissteuerung: Durch Maus, Tastatur ausgelöste Ereignisse verursachen Aufrufe von Call-back-Routinen. siehe: Konzept eingebettete Agenten OOP-2.27, Entwurfsmuster Observer OOP-3.7a * Anordnung von Komponenten (LayoutManager): Bedienelemente werden auf bestimmten Behälterflächen nach wählbaren Strategien angeordnet; siehe: Entwurfsmuster Strategy OOP-3.8 Die Mechanismen für das Zusammenwirken liegen (fast) vollständig in der wiederverwendbaren Funktionalität der Komponenten. Benutzer brauchen sie nicht (tiefgehend) zu kennen oder zu verstehen. Software-Architektur des Programmgerüstes ist Voraussetzung dafür: * Architekturgerüst ist festgelegt, so dass es für alle Anwendungsvarianten passt; * Komponenten haben unterschiedliche Aufgaben, z. B. Container, Event, Listener, LayoutManager (OOP-4.24) * Regeln zum Zusammensetzen einer Anwendungsvariante (c) 2011 bei Prof. Dr. Uwe Kastens -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 423 Ziele: Hintergrund für das Zusammenwirken in der Vorlesung: * Erinnerung an die Themen der beiden Beispiele, * Erläuterungen zum Begriff Software-Architektur, * Weiteres Beispiel: Übersetzer mit wohldefinierter Architektur nachlesen: Poetzsch-Heffter, Kap. 5.2.3.2, 5.2.3.5 -------------------------------------------------------------------------------- OOP-4.24 SWE-94 Architekturkonzept: hierarchisch strukturierte Fensterinhalte * Zusammengehörige Komponenten in einem Objekt einer Container-Unterklasse unterbringen (Panel, Window, Frame oder selbstdefinierte Unterklasse). * Eigenschaften der Objekte im Container können dann gemeinsam bestimmt werden, z. B. Farbe, LayoutManager, usw. zuordnen. * Mit Container-Objekten werden beliebig tiefe Baumstrukturen von AWT-Komponenten erzeugt. In der visuellen Darstellung sind sie ineinander geschachtelt. Frame-Objekt Panel-Objekte Label-Objekte Button-Objekte -------------------------------------------------------------------------------- Vorlesung Objektorientierte Programmierung WS 2013/2014 / Folie 424 Ziele: Beispiele für Architekturkonzepte in der Vorlesung: * Verschiedene Aufgaben von Komponenten: Frame und Panel als Container; LayoutManager * Regeln zum Zusammensetzen: Bedienelemente auf Container; LayoutManager zu Container * Voraussetzungen für automatisches Zusammenwirken * trotzdem Freiheit und Vielfalt der konstruierbaren Anwendungen nachlesen: Poetzsch-Heffter, Kap. 5.2.3, 5.3.1 --------------------------------------------------------------------------------