Wer den Begriff \u201eDaten\u201c h\u00f6rt, denkt zun\u00e4chst einmal an Zahlen, Bytes, Zeichenketten oder auch komplexe Objekte mit ihrem Zustand. Wir wollen in diesem Kapitel diese Sicht ein wenig erweitern und auf Programmcode lenken. Java-Code, versinnbildlicht als Serie von Bytecodes, besteht auch aus Daten. Und wenn wir uns einmal auf diese Sichtweise einlassen, dass Code gleich Daten ist, dann l\u00e4sst sich Code auch wie Daten \u00fcbergeben und so von einem Punkt zum anderen \u00fcbertragen, speichern und sp\u00e4ter referenzieren. Mit dieser M\u00f6glichkeit, Code zu \u00fcbertragen, l\u00e4sst sich das Verhalten von Algorithmen leicht anpassen. Beginnen wir mit ein paar Beispielen, bei denen Programmcode \u00fcbergeben wird, auf den dann sp\u00e4ter zugegriffen wird:<\/p>\n
Um Programmcode von einer Stelle zur anderen zu bringen, wird in Java immer der gleiche Mechanismus eingesetzt: Eine Klasse implementiert eine (in der Regel nichtstatische) Methode, in der der auszuf\u00fchrende Programmcode steht. Ein Objekt dieser Klasse wird an eine andere Stelle \u00fcbergeben, und der Interessent greift dann \u00fcber die Methode auf den Programmcode zu. Dass ein Objekt noch mehr als diese eine Implementierung enthalten kann, etwa Variablen, Konstanten, Konstruktoren, ist daf\u00fcr nicht relevant. Diesen Mechanismus schauen wir uns jetzt in verschiedenen Varianten genauer an.<\/p>\n
Bleiben wir bei dem Beispiel mit den Vergleichen. Angenommen, wir sollen Strings so sortieren, dass Leerraum vorne und hinten bei den Vergleichen ignoriert wird, also “ Newton “ gleich „Newton“ ist. Bei Vorgaben dieser Art muss einem Sortieralgorithmus ein St\u00fcckchen Code \u00fcbergeben werden, damit er die korrekte Reihenfolge herstellen kann. Praktisch sieht das so aus:<\/p>\n
import\u00a0java.util.*;\r\n public\u00a0class\u00a0CompareTrimmedStrings\u00a0{\r\n \u00a0\u00a0public\u00a0static\u00a0void\u00a0main(\u00a0String[]\u00a0args\u00a0)\u00a0{\r\n \u00a0\u00a0\u00a0\u00a0class\u00a0TrimmingComparator\u00a0implements\u00a0Comparator<String>\u00a0{\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0@Override\u00a0public\u00a0int\u00a0compare(\u00a0String\u00a0s1,\u00a0String\u00a0s2\u00a0)\u00a0{\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0return\u00a0s1.trim().compareTo(\u00a0s2.trim()\u00a0);\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0}\r\n \u00a0\u00a0\u00a0\u00a0}\r\n \u00a0\u00a0\u00a0\u00a0String[]\u00a0words\u00a0=\u00a0{\u00a0\"M\",\u00a0\"\\nSkyfall\",\u00a0\"\u00a0Q\",\u00a0\"\\t\\tAdele\\t\"\u00a0};\r\n \u00a0\u00a0\u00a0\u00a0Arrays.sort(\u00a0words,\u00a0new\u00a0TrimmingComparator()\u00a0);\r\n \u00a0\u00a0\u00a0\u00a0System.out.println(\u00a0Arrays.toString(\u00a0words\u00a0)\u00a0);\r\n \u00a0\u00a0}\r\n }<\/pre>\nDie Ausgabe ist:<\/p>\n
[\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Adele\u00a0\u00a0\u00a0\u00a0,\u00a0M,\u00a0\u00a0Q,\u00a0\r\n Skyfall]<\/pre>\nDer TrimmingComparator enth\u00e4lt in der compare(\u2026)-Methode den Programmcode f\u00fcr die Vergleichslogik. Ein Exemplar vom TrimmingComparator wird aufgebaut und Arrays.sort(\u2026) \u00fcbergeben. Das geht mit weniger Code!<\/p>\n
Innere anonyme Klassen als Code-Transporter<\/h4>\n
Klassen enthalten Programmcode, und Exemplare der Klassen werden an Methoden wie sort(\u2026) \u00fcbergeben, damit der Programmcode dort hinkommt, wo er gebraucht wird. Doch elegant ist das nicht. F\u00fcr die Beschreibung des Programmcodes ist extra eine eigene Klasse erforderlich. Das ist viel Schreibarbeit, und \u00fcber eine innere anonyme Klasse l\u00e4sst sich der Programmcode schon ein wenig verk\u00fcrzen:<\/p>\n
String[]\u00a0words\u00a0=\u00a0{\u00a0\"M\",\u00a0\"\\nSkyfall\",\u00a0\"\u00a0Q\",\u00a0\"\\t\\tAdele\\t\"\u00a0};\r\n Arrays.sort(\u00a0words,\u00a0new\u00a0Comparator<String>()\u00a0{\r\n \u00a0\u00a0@Override\u00a0public\u00a0int\u00a0compare(\u00a0String\u00a0s1,\u00a0String\u00a0s2\u00a0)\u00a0{\r\n \u00a0\u00a0\u00a0\u00a0return\u00a0s1.trim().compareTo(\u00a0s2.trim()\u00a0);\r\n \u00a0\u00a0}\u00a0}\u00a0);\r\n System.out.println(\u00a0Arrays.toString(\u00a0words\u00a0)\u00a0);<\/pre>\nAllerdings ist das immer noch aufw\u00e4ndig: Wir m\u00fcssen eine Methode \u00fcberschreiben und dann ein Objekt aufbauen. F\u00fcr Programmautoren ist das l\u00e4stig, und die JVM hat es mit vielen \u00fcberfl\u00fcssigen Klassendeklarationen zu tun. Die Frage ist: Wenn der Compiler wei\u00df, dass bei sort(\u2026) ein Comparator n\u00f6tig ist, und wenn ein Comparator sowieso nur eine Methode hat, muss dann Comparator und compare(\u2026) \u00fcberhaupt genannt werden?<\/p>\n
Abk\u00fcrzende Schreibweise durch Lambda-Ausdr\u00fccke<\/h4>\n
Mit Lambda-Ausdr\u00fccken l\u00e4sst sich Programmcode leichter an eine Methode \u00fcbergeben, denn es gibt eine kompakte Syntax f\u00fcr die Implementierung von Schnittstellen mit einer Operation. F\u00fcr unser Beispiel sieht das so aus:<\/p>\n
String[]\u00a0words\u00a0=\u00a0{\u00a0\"M\",\u00a0\"\\nSkyfall\",\u00a0\"\u00a0Q\",\u00a0\"\\t\\tAdele\\t\"\u00a0};\r\n Arrays.sort(\u00a0words,\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0(String\u00a0s1,\u00a0String\u00a0s2)\u00a0->\u00a0{\u00a0return\u00a0s1.trim().compareTo(s2.trim());\u00a0}\u00a0);\r\n System.out.println(\u00a0Arrays.toString(\u00a0words\u00a0)\u00a0);<\/pre>\nDer in fett gesetzte Ausdruck nennt sich Lambda-Ausdruck. Er ist eine kompakte Art und Weise, Schnittstellen mit genau einer Methode zu implementieren; die Schnittstelle Comparator hat genau eine Operation compare(\u2026).<\/p>\n
Optisch sind sich ein Lambda-Ausdruck und eine Methodendeklaration \u00e4hnlich; was wegf\u00e4llt sind Modifizierer, der R\u00fcckgabetyp, der Methodenname und (m\u00f6gliche) throws-Klauseln.<\/p>\n
| Methodendeklaration<\/td>\n | Lambda-Ausdruck<\/td>\n<\/tr>\n |
| public\u00a0int\u00a0compare \n(\u00a0String\u00a0s1,\u00a0String\u00a0s2\u00a0)<\/p>\n {\u00a0return\u00a0s1.trim().compareTo(\u00a0s2.trim()\u00a0);\u00a0}<\/td>\n | \n(\u00a0String\u00a0s1,\u00a0String\u00a0s2\u00a0) \n-> \n{\u00a0return\u00a0s1.trim().compareTo(\u00a0s2.trim()\u00a0);\u00a0}<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Tabelle 1.1: Vergleich der Methodendeklaration einer Schnittstelle mit dem Lambda-Ausdruck<\/p>\n Wenn wir uns den Lambda-Ausdruck als Implementierung dieser Schnittstelle anschauen, dann l\u00e4sst sich dort nichts von Comparator oder compare(\u2026) ablesen \u2013 ein Lambda-Ausdruck repr\u00e4sentiert mehr oder weniger nur den Java-Code und l\u00e4sst das, was der Compiler aus dem Kontext herleiten kann, weg.<\/p>\n Alle Lambda-Ausdr\u00fccke lassen sich in einer Syntax formulieren, die die folgende allgemeine Form hat:<\/p>\n (\u00a0LambdaParameter\u00a0)\u00a0->\u00a0{\u00a0Anweisungen\u00a0}<\/pre>\n |