Ausblick: Entwurfsmuster (Design Pattern)

Werbung
Ausblick:
Entwurfsmuster (Design Pattern)
12.1
12.2
12.3
12.4
Entwurfsmuster (Design Pattern)
Programmierparadigmen und -sprachen
Gegenstände der Software-Technik
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
12.2
12.3
12.4
Entwurfsmuster (Design Pattern)
Programmierparadigmen und -sprachen
Gegenstände der Software-Technik
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
do r :=
a :=
b :=
od
# 0
a mod b;
b;
r
12.2 Programmierparadigmen und -sprachen
12-20
Algorithmus von Euklid
Variable
r
a
b
z2
–
36
52
z5
36
52
36
z8
16
36
16
z11
4
16
4
z14
0
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 #
do r :=
a :=
b :=
od
0
a mod b;
b;
r
• funktionale/rekursive Formulierung:
(
a
b=0
ggT(a,b) =
ggT(b, a mod b) b =
6 0
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
.
.
2000
C#
1995
Programmiersprachen in der
Informatikausbildung
JAVA
SCHEME (standard)
1990
• Algol
OCCAM
C++
1985
CSP
ADA
1980
SMALLTALK80
MODULA−2
1975 C
SCHEME
PROLOG
PASCAL
1970
ALGOL68
• Algol68
• Modula-2
LOGO
SIMULA
• Scheme
1965 PL/I
BASIC
1960
1955
COBOL
ALGOL
LISP
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
12.2
12.3
12.4
Entwurfsmuster (Design Pattern)
Programmierparadigmen und -sprachen
Gegenstände der Software-Technik
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
Einzelkunde
Firmenkunde
Verwalte
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
Farbe : Colour
12.3 Gegenstände der Software-Technik
Quadrat
Dreieck
Icon
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
12.2
12.3
12.4
Entwurfsmuster (Design Pattern)
Programmierparadigmen und -sprachen
Gegenstände der Software-Technik
Java 8
12.4 Java 8
12-55
Bisherige Entwicklung von Java
1992–1995
Jan.
Anfang
Dez.
Jan.
Mai
Februar
Ende
Dezember
Juli
12.4 Java 8
1996
1997
1998
1999
2000
2002
2004
2006
2011
Java-Vorläufer, zuerst unter dem Namen „Oak“.
Neu: Applets (little applications)
JDK 1.0 (Java Development Kit)
JDK 1.1
JDK 1.2, wurde
umbenannt in „Java 2 Plattform“
Java 2, JDK 1.3
Java 2, JDK 1.4
Java 2, JDK 5.0 (interne Versionsnummer: 1.5.0) „Tiger“
Java Standard Edition 6 („Mustang“)
Java Standard Edition 7 („Dolphin“)
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
Herunterladen