Ausblick: Entwurfsmuster (Design Pattern) - 12.1 Entwurfsmuster (Design Pattern) 12.2 Programmierparadigmen und -sprachen 12.3 Gegenstände der ...
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Ausblick: Entwurfsmuster (Design Pattern) 12.1 Entwurfsmuster (Design Pattern) 12.2 Programmierparadigmen und -sprachen 12.3 Gegenstände der Software-Technik 12.4 Java 8 12.1 Entwurfsmuster (Design Pattern) 12-1
Entwurfsmuster (Design Pattern) • Als Entwurfsmuster bezeichnet man einen wohl überlegten Vorschlag für den Entwurf eines objektorientierten Programmierproblems. Es beschreibt in rezeptartiger Weise das Zusammenwirken von Klassen, Objekten und Methoden. Entwurfsmuster identifizieren Programmierprobleme und geben den Software-Entwürfen charakterisierende Namen. • Entwurfsmuster stellen wie Algorithmen oder Datenstrukturen vordefinierte Lösungen für konkrete Programmierprobleme dar, allerdings auf einer höheren Ebene. In der Regel können Entwurfsmuster nicht in allen Details übernommen werden, sondern müssen an das jeweilige Problem angepasst werden. • Entwurfsmuster sind eine der wichtigsten Entwicklungen der objektorientierten Programmierung der letzten zwanzig Jahre. 12.1 Entwurfsmuster (Design Pattern) 12-2
Entwurfsmuster Beispiele für Entwurfsmuster sind: • Singleton • Immutable • Observer • Composite • Interface • Factory • Iterator • Delegate • Visitor Wir erläutern die Idee jetzt an drei einfachen Beispielen. 12.1 Entwurfsmuster (Design Pattern) 12-3
Das Entwurfsmuster „Singleton“ • Ein Singleton ist eine Klasse, von der nur ein einziges Objekt erstellt werden darf. • Sie stellt eine Zugriffsmöglichkeit auf dieses Objekt zur Verfügung und instanziiert es beim ersten Zugriff. • Es gibt viele Beispiele für Singletons. Hier seien nur der Fenstermanager oder die Symboltabelle eines Compilers genannt. 12.1 Entwurfsmuster (Design Pattern) 12-4
Das Entwurfsmuster „Singleton“ Merkmale der folgenden Implementierung sind: • Sie besitzt ein statisches Attribut ihres eigenen Typs, in dem die einzige Instanz gespeichert wird. • Mithilfe der statischen Methode getInstance() kann auf die Instanz zugegriffen werden. • Die Klasse enthält einen privaten parameterlosen Konstruktor. So wird verhindert, dass andere Klassen den new-Operator anwenden und weitere Instanzen erzeugen. 12.1 Entwurfsmuster (Design Pattern) 12-5
Das Entwurfsmuster „Singleton“ public class Singleton { private static Singleton instance = null; private Singleton() { } public static Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } } 12.1 Entwurfsmuster (Design Pattern) 12-6
Das Entwurfsmuster „Singleton“ // Singleton s1 = new Singleton(); gibt Fehler Singleton s2 = Singleton.getInstance(); // new wird aufgerufen Singleton s3 = Singleton.getInstance(); // new wird nicht aufgerufen 12.1 Entwurfsmuster (Design Pattern) 12-7
Das Entwurfsmuster „Immutable“ • Als immutable (unveränderlich) werden Objekte bezeichnet, die nach ihrer Instanziierung nicht mehr verändert werden können. • Unveränderliche Objekte können gefahrlos mehrfach referenziert werden und erfordern im Multithreading keinen Synchronisationsaufwand. 12.1 Entwurfsmuster (Design Pattern) 12-8
Das Entwurfsmuster „Immutable“ Merkmale der folgenden Implementierung sind: • Alle Attribute sind privat. • Schreibende Zugriffe finden nur in einem Konstruktor oder in Initalisierern statt. • Lesende Zugriffe sind verboten, wenn das Attribut ein veränderliches Objekt oder ein Array ist. • Werden veränderliche Objekte oder Arrays an einen Konstruktor übergeben, so müssen sie geklont werden, bevor sie einer Attributvariablen zugewiesen werden. 12.1 Entwurfsmuster (Design Pattern) 12-9
Das Entwurfsmuster „Immutable“ public class Immutable { private int value1; private String[] value2; public Immutable(int value1, String[] value2) { this.value1 = value1; this.value2 = (String[]) value2.clone(); } 12.1 Entwurfsmuster (Design Pattern) 12-10
public int getValue1() { return value1; } public String getValue2(int index) { return value2[index]; } } 12.1 Entwurfsmuster (Design Pattern) 12-11
Das Entwurfsmuster „Immutable“ • Durch Ableitung könnte ein unveränderliches Objekt wieder veränderlich werden. Zwar ist es der abgeleiteten Klasse nicht möglich, die privaten Attribute zu überschreiben, sie könnte aber eigene Attribute einführen, die veränderbar sind. • Erforderlichenfalls muss die Klasse als final deklariert werden. 12.1 Entwurfsmuster (Design Pattern) 12-12
Das Entwurfsmuster „Observer“ • Das Observer-Pattern beschreibt die Idee, bestimmte Objekte auf Veränderungen ihres Zustands zu überwachen. • Die überwachten Objekte, die sog. Observables, informieren die ihnen bekannt gemachten Observer von den Veränderungen. • Auf diese Weise werden die Veränderungen der Daten und die daraus resultierenden Aktionen entkoppelt. • Das Observer-Pattern ist eines der in Java am häufigsten benutzten Entwurfsmuster, zum Beispiel als „Listener“. 12.1 Entwurfsmuster (Design Pattern) 12-13
Das Entwurfsmuster „Observer“ • Die zugrunde liegende Idee ist die Verwendung einer Klasse Observable, deren Objekte überwacht werden sollen. Diese Klasse enthält (mindestens) ◦ ein privates Observer-Attribut sowie ◦ Methoden zum Hinzufügen und Löschen von Observern. • Außerdem gibt es die Klasse Observer, ◦ in deren Konstruktor, die Anmeldung beim zu beobachtenden Objekt erfolgt sowie ◦ eine Update-Methode, in der die Reaktion auf die Veränderung spezifiziert wird. • Wir erläutern jetzt dieses Entwurfsmuster an einem einfachen Beispiel mit nur einem Beobachter. Beobachtet werden Objekte der Klasse Name auf Veränderungen des Attributs String name. 12.1 Entwurfsmuster (Design Pattern) 12-14
Das Entwurfsmuster „Observer“ public class Name { private String name; private Observer observer; // bei mehreren Beobachtern: Vector public void setObserver(Observer observer) { this.observer = observer; } public void deleteObserver(Observer observer) { this.observer = null; } public void setName(String name) { this.name = name; if (observer != null) observer.update(this); } public String getName() { return name; } } 12.1 Entwurfsmuster (Design Pattern) 12-15
Das Entwurfsmuster „Observer“ public class Observer { private Name[] namen; public Observer() { namen = new Name[10]; for (int i = 0; i < namen.length; i++) { namen[i] = new Name(); namen[i].setObserver(this); }} public void update(Name n) { int index = 0; while (n != namen[index]) index++; System.out.println("Name Nr. " + index + " wurde geändert."); System.out.println("Neuer Name: " + namen[index].getName()); } public Name getName(int i) { return namen[i]; } } 12.1 Entwurfsmuster (Design Pattern) 12-16
Das Entwurfsmuster „Observer“ import java.util.Scanner; public class Test { public static void main(String[] args) { Observer obs = new Observer(); for (int i = 0; i < 5; i++) { Scanner sc = new Scanner(System.in); int index = (int) (Math.random() * 10); System.out.print("Name: "); obs.getName(index).setName(sc.next()); } } } 12.1 Entwurfsmuster (Design Pattern) 12-17
Ausblick: Programmierparadigmen und -sprachen 12.1 Entwurfsmuster (Design Pattern) 12.2 Programmierparadigmen und -sprachen 12.3 Gegenstände der Software-Technik 12.4 Java 8 12.2 Programmierparadigmen und -sprachen 12-18
Wiederholung: Paradigmen zur Algorithmenbeschreibung In einem objektorientierten Algorithmus werden Datenstrukturen und Methoden zu einer Klasse zusammengefasst. Von jeder Klasse können Objekte gemäß der Datenstruktur erstellt und über die Methoden manipuliert werden. In einem imperativen Algorithmus gibt es Variable, die verschiedene Werte annehmen können. Die Menge aller Variablen und ihrer Werte sowie der Programmzähler beschreiben den Zustand zu einem bestimmten Zeitpunkt. Ein Algorithmus bewirkt eine Zustandstransformation. Ein Algorithmus heißt funktional, wenn die zugrunde liegende Berechnungsvorschrift mittels einer Sammlung von Funktionen definiert wird. Die Funktionsdefinitionen dürfen insbesondere Rekursionen und Funktionen höherer Ordnung enthalten. 12.2 Programmierparadigmen und -sprachen 12-19
Algorithmus von Euklid Der folgende, in einer imperativen Programmiersprache formulierte Algorithmus von Euklid berechnet den größten gemeinsamen Teiler der Zahlen x , y ∈ N mit x ≥ 0 und y > 0: a := x; b := y; while b # 0 do r := a mod b; a := b; b := r od 12.2 Programmierparadigmen und -sprachen 12-20
Algorithmus von Euklid Variable z2 z5 z8 z11 z14 r – 36 16 4 0 a 36 52 36 16 4 b 52 36 16 4 0 ggT(36, 52) = 4 Durchlaufene Zustände: z0, z1, z2, ... , z14 Zustandstransformation: z0 7−→ z14 12.2 Programmierparadigmen und -sprachen 12-21
Imperatives Programmieren • In einem imperativen Programm gibt es Variable, die Werte speichern können. Die Variablen und ihre Werte legen den Zustand des Programms fest. Der Zustand ändert sich mit dem Ablauf des Programms. • Die Wertzuweisung gestattet es, den Zustand zu verändern. • ◦ Mit einer Sequenz können Anweisungen nacheinander ausgeführt werden. ◦ Die Selektion erlaubt die Auswahl zwischen Anweisungen. ◦ Anweisungen können mit der Iteration wiederholt werden. • ◦ Eingabe-Anweisungen ermöglichen es, den Zustand von außen zu beeinflussen. ◦ Ausgabe-Anweisungen erstellen einen Ausdruck des Zustands (oder eines Teils davon). 12.2 Programmierparadigmen und -sprachen 12-22
Imperatives Programmieren • Prozeduren: Abstraktionen von Anweisungen • Funktionen: Abstraktionen von Ausdrücken • Datentypen: ◦ Primitive Datentypen: boolean, char, int, real ◦ Zusammengesetzte Datentypen: enumeration, array, record, pointer ◦ Typdeklarationen: Abstraktionen von Datentypen Typsysteme können unabhängig von Paradigmen und Sprachen definiert und untersucht werden. 12.2 Programmierparadigmen und -sprachen 12-23
Imperatives Programmieren • Weitere Kontrollstrukturen • Module • Ausnahmebehandlung • Parallelverarbeitung 12.2 Programmierparadigmen und -sprachen 12-24
Algorithmus von Euklid • imperative/iterative Formulierung: while b # 0 do r := a mod b; a := b; b := r od • funktionale/rekursive Formulierung: ( a b=0 ggT(a,b) = 6 0 ggT(b, a mod b) b = 12.2 Programmierparadigmen und -sprachen 12-25
Algorithmus von Euklid (Scheme, funktional) (define (ggT a b) (if (= b 0) a (ggT b (remainder a b)))) (ggt 36 52) > 4 12.2 Programmierparadigmen und -sprachen 12-26
Funktionales Programmieren • Ein funktionaler Algorithmus formuliert die Berechnungsvorschrift durch eine Menge von Funktionen. • Die Funktionen können wechselseitig-rekursiv oder auch • von höherer Ordnung (Funktionale) sein. 12.2 Programmierparadigmen und -sprachen 12-27
Funktionen höherer Ordnung (define (inc n) (+ n 1)) (define (square x) (* x x)) (define (cube x) (* x x x)) (define (sum f a next b) (if (> a b) 0 (+ (f a) (sum f (next a) next b)))) 12.2 Programmierparadigmen und -sprachen 12-28
(define (sum-square a b) (sum square a inc b)) (define (sum-cube a b) (sum cube a inc b)) > (sum-square 1 4) 30 > (sum-cube 1 4) 100 12.2 Programmierparadigmen und -sprachen 12-29
Deduktive Algorithmen • Ein deduktiver (logischer) Algorithmus führt Berechnungen durch, indem er aus Fakten und Regeln weitere Fakten, sogenannte Anfragen (Ziele), beweist. • Fakten: P • Regeln: P if Q1 and Q2 and ... and Qk Regeln dieser Form werden auch Horn-Klauseln genannt. Fakten können als Regeln mit k = 0 gesehen werden. • Die folgenden Beispiele wurden in der deduktiven Programmiersprache Prolog geschrieben. 12.2 Programmierparadigmen und -sprachen 12-30
Beispiel: Eingabe der Fakten und Regeln vater(johann,heinrich). vater(johann,thomas). vater(heinrich,carla). vater(thomas,erika). vater(thomas,klaus). vater(thomas,golo). vater(thomas,monika). vater(thomas,elisabeth). vater(thomas,michael). verheiratet(johann,julia). verheiratet(heinrich,maria). verheiratet(thomas,katia). mutter(X,Y) :- vater(Z,Y), verheiratet(Z,X). geschwister(X,Y) :- vater(Z,X), vater(Z,Y), X \= Y. 12.2 Programmierparadigmen und -sprachen 12-31
Beispiel: Eingabe der Anfragen Nachdem das Programm eingelesen wurde, können Anfragen gestellt werden, die von einer Interferenzmaschine, zum Beispiel einem Prolog-Interpreter, beantwortet werden. Anfragen werden nach der Eingabeaufforderung | ?- gestellt: | ?- geschwister(thomas, heinrich). true ? ; no | ?- geschwister(thomas, golo). no Die Ausgabe true bedeutet, dass die Anfrage positiv beantwortet wurde, das heißt, dass Thomas und Heinrich Geschwister sind. Nach einem Fragezeichen erwartet der Interpreter Anweisungen, wie fortzufahren ist. Ein Semikolon ist die Aufforderung, nach weiteren Lösungen zu suchen. 12.2 Programmierparadigmen und -sprachen 12-32
Beispiel: Eingabe der Anfragen Falls eine Anfrage eine Variable enthält, werden alle Belegungen für die Variablen ermittelt, die die Aussage wahr werden lassen. Wenn wir die Geschwister von Golo suchen, stellen wir die folgende Anfrage. | ?- geschwister(X,golo). X = erika ? ; X = klaus ? ; X = monika ? ; X = elisabeth ? ; X = michael ? ; no Erika, Klaus, Monika, Elisabeth und Michael sind also die Geschwister von Golo. 12.2 Programmierparadigmen und -sprachen 12-33
Beispiel: Eingabe der Anfragen Eine Anfrage kann mehr als eine Variable enthalten. Durch | ?- geschwister(X,Y). werden insgesamt 32 Geschwisterpaare ermittelt, da Paare wegen der Symmetrie der Relation doppelt ausgegeben werden. 12.2 Programmierparadigmen und -sprachen 12-34
Algorithmus von Euklid (Prolog, deduktiv) ggt(A,0,A). ggt(A,B,Z) :- U is A mod B, ggt(B,U,Z). | ?- ggt(36,52,Z). Z = 4 ? 12.2 Programmierparadigmen und -sprachen 12-35
Funktionen und Relationen • Eine Funktion f : X −→ Y ordnet jedem Element der Menge X (Definitionsbereich) genau ein Element der Menge Y (Wertebereich) zu: x 7−→ f (x ) • Eine Relation R ⊆ X × Y besteht aus Paaren (x , y ) ∈ X × Y . Dabei kann es zu einem x ∈ X mehrere Elemente y ∈ Y mit (x , y ) ∈ R geben. 12.2 Programmierparadigmen und -sprachen 12-36
Deduktives Programmieren • Deduktives Programmieren beschäftigt sich mit Relationen und nicht mit Funktionen. • Fakten und Regeln können als Eingabe von Relationen bzw. als Konstruktionsvorschriften für Relationen angesehen werden. • Anfragen überprüfen, ob Paare in einer bestimmten Relation stehen oder ermitteln solche Paare: ◦ Eine Anfrage der Form P(x , y ) überprüft, ob x und y bezüglich P in Relation stehen. ◦ Die Anfrage P(X , y ) berechnet alle x mit (x , y ) ∈ P. ◦ Anfragen der Form P(X , Y ) führen zur Ausgabe aller Paare (x , y ) mit (x , y ) ∈ P. 12.2 Programmierparadigmen und -sprachen 12-37
Deklaratives Programmieren • In deklarativen Programmiersprachen wird aus einer nach bestimmten Regeln gebildeten mathematischen Formulierung eines Problems automatisch ein Programm erzeugt. • Die formale Problembeschreibung kann z. B. auf der Prädikatenlogik (logische Programmiersprachen) oder dem λ-Kalkül (funktionale Programmiersprachen) basieren. • Deklarative Programmiersprachen haben sich vom Konzept der ausführenden Maschine gelöst. 12.2 Programmierparadigmen und -sprachen 12-38
Entwicklung der Programmiersprachen . Programmiersprachen in der . 2000 C# Informatikausbildung 1995 JAVA 1990 SCHEME (standard) • Algol C++ OCCAM 1985 1980 ADA SMALLTALK80 CSP • Algol68 MODULA−2 SCHEME 1975 C • Modula-2 PROLOG PASCAL 1970 LOGO ALGOL68 SIMULA 1965 PL/I • Scheme BASIC 1960 COBOL ALGOL LISP 1955 FORTRAN • Java . 12.2 Programmierparadigmen und -sprachen 12-39
Programmiersprachen • Imperative Programmiersprachen: Cobol, Fortran, PL/I, Basic, Algol, Algol68, Pascal, Modula-2, C, Ada • Funktionale Programmiersprachen: Lisp, Scheme, ML, Haskell, Scala. Die Sprache Scala ist eine Erweiterung von Java. • Objektorientierte Programmiersprachen: C++, Eiffel, Smalltalk, Java, C#, Oberon • Logische Programmiersprachen: Prolog • Skriptsprachen, Spezialsprachen 12.2 Programmierparadigmen und -sprachen 12-40
Ausblick: Gegenstände der Software-Technik 12.1 Entwurfsmuster (Design Pattern) 12.2 Programmierparadigmen und -sprachen 12.3 Gegenstände der Software-Technik 12.4 Java 8 12.3 Gegenstände der Software-Technik 12-41
Was ist Software-Technik? W. Hesse, H. Keutgen, A. L. Luft, H. D. Rombach: Ein Begriffsystem für die Software-Technik, Informatik-Spektrum, 7, 1984, S. 200–213: Software-Technik (Software-Engineering) ist das Teilgebiet der Informatik, das sich mit der Bereitstellung und systematischen Verwendung von Methoden und Werkzeugen für die Herstellung und Anwendung von Software beschäftigt. 12.3 Gegenstände der Software-Technik 12-42
Software-Technik • setzt solide Kenntnisse in (mindestens) einer Programmiersprache voraus, • ist nicht auf eine spezielle Programmiersprache (sondern evtl. eher auf ein Paradigma) zugeschnitten, • ist ein weites und wichtiges Gebiet der Informatik. 12.3 Gegenstände der Software-Technik 12-43
Teilgebiete der Software-Technik • Software-Entwicklung • Software-Management • Software-Qualitätssicherung 12.3 Gegenstände der Software-Technik 12-44
Software-Entwicklung • Planungsphase • Definitionsphase • Entwurfsphase • Implementierungsphase • Abnahme- und Einführungsphase • Wartungs- und Pflegephase 12.3 Gegenstände der Software-Technik 12-45
Software-Management • Planung • Organisation • Personaleinsatz • Leitung • Kontrolle 12.3 Gegenstände der Software-Technik 12-46
Software-Qualitätssicherung • Qualitätssicherung • Prüfmethoden • Prozessqualität • Produktqualität 12.3 Gegenstände der Software-Technik 12-47
Weitere Aspekte • Werkzeuge, Computer Aided Software Engineering (CASE) • Wiederverwendbarkeit von Software • Modellierung, z. B. Unternehmensmodellierung • Modellierungsprachen, z. B. UML • Langlebigkeit 12.3 Gegenstände der Software-Technik 12-48
Unified Modelling Language • UML (Unified Modelling Language) wurde in den 1990er Jahren mit dem Ziel, eine einheitliche – auch grafische – Notation für die objektorientierte Software-Entwicklung zur Verfügung zustellen, definiert. • Derzeitige Version: UML 2.4.1 (August 2011) • Sie enthält ca. ein Dutzend verschiedener Modelltypen zur Beschreibung der verschiedenen Systemaspekte. • Die ersten Entwickler der UML waren Grady Booch, Ivar Jacobson und James Rumbaugh. • UML werden Sie in den Veranstaltungen zur Software-Technik kennen lernen. 12.3 Gegenstände der Software-Technik 12-49
Unified Modelling Language • Anwendungsfalldiagramm (Benutzersicht) • Implementierungsdiagramme (Strukturdiagramme, statische Systemstruktur) ◦ Klassendiagramm ◦ Objektdiagramm ◦ Komponentendiagramm ◦ Paketdiagramm ◦ Verteilungsdiagramm ◦ Kompositionsstrukturdiagramm 12.3 Gegenstände der Software-Technik 12-50
Unified Modelling Language • Verhaltensdiagramme (Verhaltensdiagramme, dynamisches Systemverhalten) ◦ Aktivitätsdiagramm ◦ Zustandsdiagramm ◦ Kollaborationsdiagramme ◦ Kommunikationsdiagramm ◦ Timingdiagramm ◦ Sequenzdiagramm ◦ Interaktionsübersichtsdiagramm 12.3 Gegenstände der Software-Technik 12-51
Anwendungsfalldiagramme • modellieren die Einbettung eines Systems in seine Umgebung, • beschreiben die Sicht auf Systemfunktionalität von außen und • werden zur Spezifikation der globalen Systemanforderungen eingesetzt. Kreditkarten-Validierungssystem Fuehre Kartentransaktion durch Kunde Haendler Bearbeite Rechnung Verwalte Einzelkunde Firmenkunde Kundenkonto Finanzinstitut 12.3 Gegenstände der Software-Technik 12-52
Klassendiagramme • stellen die statische Systemstruktur dar und • beschreiben die Systemelemente und ihre Beziehungen zueinander. Bitmap Bildschirm zeichnen() +Elemente Pixel x : Integer y : Integer Quadrat Dreieck Icon Farbe : Colour 12.3 Gegenstände der Software-Technik 12-53
Sequenzdiagramme • stellen die Abfolge der Nachrichten dar. • Sie basieren auf “Message Sequence Charts”. Reader Librarian System hand_book enter_book_data update [reserved] notify acknowledge_librarian acknowledge_reader 12.3 Gegenstände der Software-Technik 12-54
Ausblick: Java 8 12.1 Entwurfsmuster (Design Pattern) 12.2 Programmierparadigmen und -sprachen 12.3 Gegenstände der Software-Technik 12.4 Java 8 12.4 Java 8 12-55
Bisherige Entwicklung von Java 1992–1995 Java-Vorläufer, zuerst unter dem Namen „Oak“. Neu: Applets (little applications) Jan. 1996 JDK 1.0 (Java Development Kit) Anfang 1997 JDK 1.1 Dez. 1998 JDK 1.2, wurde Jan. 1999 umbenannt in „Java 2 Plattform“ Mai 2000 Java 2, JDK 1.3 Februar 2002 Java 2, JDK 1.4 Ende 2004 Java 2, JDK 5.0 (interne Versionsnummer: 1.5.0) „Tiger“ Dezember 2006 Java Standard Edition 6 („Mustang“) Juli 2011 Java Standard Edition 7 („Dolphin“) 12.4 Java 8 12-56
Java 8 • Eigentlich sollte Java 8 im September 2013 veröffentlicht werden. • Den genauen Termin hat der verantworliche Ingenieur Mark Reinhold bei Oracle jetzt auf den 18. März 2014 festgelegt. • Die folgenden Aussagen zu Java 8 erfolgen ohne Garantie. 12.4 Java 8 12-57
Fragestellung: Statischer/dynamischer Scope Wie lautet die Ausgabe des folgenden Programms? public class Test { static int x=7; static void p() {x=0;} // x ist eine globale Variable. public static void main(String[] args) { int x=5; p(); System.out.println(x); } } • Statischer Scope: Ausgabe: 5, Dynamischer Scope: Ausgabe: 0. • Die Semantik der Methode p hängt also davon ab, wie die globale Variable x genommen wird. • Wir wissen: Java gibt die 5 aus. 12.4 Java 8 12-58
Java 8 • Die wichtigste Erweiterung ist das Projekt Lambda. Das Ziel dieses Projektes ist die Einführung von Closures. Damit wird die Bedeutung von globalen Variablen definiert. Globale Variable können vielfältiger als das obige Beispiel sein. • Funktionale Schnittstellen sind Schnittstellen, die genau eine abstrakte Methode enthalten. Abstrakte Klassen mit einer abstrakten Methode zählt man nicht zu den funktionalen Schnittstellen. Schnittstellen sollen auch statische Methoden enthalten können. • Eine wichtige Erweiterung sind Lambda-Ausdrücke. Ein Lambda-Ausdruck ist ein Literal, das eine funktionale Schnittstelle implementiert, ohne der Funktion einen Namen zu geben. • Die API muss erweitert werden: Lambda, Java Collections Framework, ... 12.4 Java 8 12-59
Closures Friedrich Esser: Ein Closure ist ein Block bzw. eine Einheit von Code, der freie Variable aus der Umgebung, genauer dem umgebenden Scope zur Berechnung des Ergebnisses mit einbezieht. Abhängig von der Art der freien Variablen, gibt es Closures, deren – Ergebnisse nur von ihren Argumenten abhängen, da die freien Variablen immutable sind. – Ergebnisse mit den mutablen Werten der freien Variablen variieren. Leider wird Closure je nach Autor oder Sprache ein wenig anders interpretiert. 12.4 Java 8 12-60
Sie können auch lesen