Bevor wir zu n\u00e4chsten Punkt kommen, m\u00fcssen wir noch einmal inne halten und uns fragen, was denn das Kernkonzept der objektorientierten Programmierung ist. Wohl ohne zu Z\u00f6gern k\u00f6nnen wir Klassen und Kapselung nennen. Klassen und Klassenbeziehungen das Ger\u00fcst jedes Java-Programms. Schauen wir uns Vererbung noch einmal genauer an, so wissen wir, das Unterklassen Spezialisierungen sind, und das Liskovsche Substitutionsprinzip gilt: Falls ein Typ gefordert ist, k\u00f6nnen wir auch einen Untertyp \u00fcbergeben. So sollte perfekte Vererbung aussehen: Eine Unterklasse sollte das Verhalten spezialisieren, aber nicht einfach von einer Klasse erben, weil sie n\u00fctzliche Funktionalit\u00e4t hat. Aber warum eigentlich nicht? Ein Problem ist, das uns die Einfachvererbung nur eine einzige Oberklasse erlaubt. Wenn eine Klasse so etwas N\u00fctzliches wie Logging anbietet, und unsere Klasse davon erbt, kann sie nicht gleichzeitig von einer anderen Klasse erben, um zum Beispiel Zust\u00e4nde in Konfigurationsdaten festzuhalten. Das Problem bei der \u201eFunktionalit\u00e4tsvererbung\u201c ist also, dass wir uns nur einmal festlegen k\u00f6nnen. Wenn eine Klasse eine gewisse Funktionalit\u00e4t einfach braucht, woher soll sie denn dann kommen, wenn nicht aus der Oberklasse? Eigentlich gibt es hier nur eine naheliegende Variante: Die Klasse greift auf andere Objekte zur\u00fcck per Delegation. Das ist interessant, aber auch nicht optimal, insbesondere gilt dann nicht die ist-eine-Art-von-Beziehung. Falls das nicht gew\u00fcnscht ist, ist das in Ordnung, doch wenn \u00fcber diesen Typ eine Abstraktion l\u00e4uft, ist das ung\u00fcnstig. <\/p>\n
Ein Dilemma. Gut w\u00e4re eine Technik, die einen Programmbaustein in eine Klasse setzen kann. Im Grunde so etwas wie Mehrfachvererbung, aber doch anders, weil die Bausteine nicht als komplette Typen auftreten \u2013 der Baustein selbst ist nur ein Implantat und alleine uninteressant. Auch ein Objekt kann von diesem Baustein-Typ nicht erzeugt werden.<\/p>\n
Am ehesten sind die Bausteine mit abstrakten Klassen vergleichbar, doch das w\u00e4ren Klassen und Nutzer k\u00f6nnten nur einmal von diesem Baustein erben. Mit Java 8 gibt es aber eine ganz neue M\u00f6glichkeit, und zwar mit den erweiterten Schnittstelle: Sie bilden die Bausteine, von denen Klassen Funktionalit\u00e4t bekommen k\u00f6nnen. Andere Programmiersprachen bieten so etwas \u00c4hnliches und das Konzept wird dort Mixin oder Trait genannt.[1]<\/a> Diese Bausteine sind n\u00fctzlich, denn so l\u00e4sst sich ein Algorithmus in eine extra Compilationseinheit setzen und leichter wiederverwenden. Ein Beispiel.<\/p>\n Nehmen wir zwei erweiterte Schnittelle an: PersistentPreference und Logged. Die erste erweiterte Schnittstelle soll mit store() Schl\u00fcssel\/Werte-Paare in die zentrale Konfiguration schreiben und get() soll sie auslesen:<\/p>\n import java.util.prefs.Preferences;<\/p>\n interface PersistentPreference {<\/p>\n default void store( String key, String value ) {<\/p>\n Preferences.userRoot().put( key, value );<\/p>\n }<\/p>\n default String get( String key ) {<\/p>\n return Preferences.userRoot().get( key, "" );<\/p>\n }<\/p>\n }<\/p>\n Die zweite erweiterte Schnittstelle ist Logged und bietet drei kompakte Logger-Methoden:<\/p>\n import java.util.logging.*;<\/p>\n interface Logged {<\/p>\n default void error( String message ) {<\/p>\n Logger.getLogger( getClass().getName() ).log( Level.SEVERE, message );<\/p>\n }<\/p>\n default void warn( String message ) {<\/p>\n Logger.getLogger( getClass().getName() ).log( Level.WARNING, message );<\/p>\n }<\/p>\n default void info( String message ) {<\/p>\n Logger.getLogger( getClass().getName() ).log( Level.INFO, message );<\/p>\n }<\/p>\n }<\/p>\n Eine Klasse kann diese Bausteine nun einbauen:<\/p>\n class Player implements PersistentPreference, Logged {<\/p>\n \/\/ \u2026<\/p>\n }<\/p>\n Die Methoden sind nun Teil vom Player und k\u00f6nnen auch von Unterklassen \u00fcberschrieben werden. Als Aufgabe f\u00fcr den Leser bleibt, die Implementierung von store() im Player zu ver\u00e4ndern, dass der Schl\u00fcssel immer mit \u201eplayer.\u201c beginnt. Die Frage, die Leser beantworten sollten ist, ob store() von Player auf das store() von der erweiterten Schnittstelle zugreifen kann. <\/p>\n Default-Methoden weiter gedacht<\/strong><\/p>\n F\u00fcr diese Bausteine, also die erweiterten Schnittstellen, gibt es viele Anwendungsf\u00e4lle. Da die Java- Bibliothek schon an die 20 Jahre als ist, w\u00fcrden heute einige Typen anders aussehen. Dass sich Objekte mit equals() vergleichen lassen k\u00f6nnen, k\u00f6nnte heute zum Beispiel in einer erweiterten Schnittstelle stehen, etwa so: interface Equals { boolean equals( Object that ) default { return this == that; } }. So m\u00fcsste java.lang.Object die Methode nicht f\u00fcr alle vorschreiben, wobei das sicherlich jetzt kein Nachteil ist. Nat\u00fcrlich gilt das gleiche auf f\u00fcr die hashCode()-Methode, die heutzutage aus einer erweiterten Schnittstelle Hashable stammen k\u00f6nnte.<\/p>\n Und java.lang.Number ist ein weiters Beispiel. Die abstrakte Basisklasse f\u00fcr Werte-repr\u00e4sentierende Objekte deklariert die abstrakten Methoden doubleValue(), floatValue(), intValue(), longValue() und die konkreten Methoden byteValue() und shortValue(). Bisher erben AtomicInteger<\/a>, AtomicLong<\/a>, BigDecimal<\/a>, BigInteger<\/a>, Byte<\/a>, Double<\/a>, Float<\/a>, Integer<\/a>, Long<\/a>, Short<\/a> von dieser Oberklasse. Auch diese Funktionalit\u00e4t lie\u00dfe sich mit einer erweiterten Schnittstelle umsetzen.<\/p>\n Da Schnittstellen auch Generics haben k\u00f6nnen, werden Default-Methoden noch vielseitiger. Baustein k\u00f6nnen auch andere Bausteine erweitern, da eine Schnittstelle andere Schnittstellen extenden kann. Es ist dabei egal, ob die die Schnitten erweitert sind oder nicht.<\/p>\n Zustand in den Bausteinen?<\/strong><\/p>\n Nicht jeder w\u00fcnschenswerte Baustein ist mit erweiterten Schnittstellen m\u00f6glich. Ein Grund ist, dass die Schnittstellen keinen Zustand einbringen k\u00f6nnen. Einen Baustein f\u00fcr einen Container k\u00f6nnen wir nicht so einfach implementieren, da ein Container Kinder verwaltet, und hierf\u00fcr ist eine Objektvariable f\u00fcr den Zustand n\u00f6tig. Schnittstellen haben nur statische Variablen und die sind f\u00fcr alle sichtbar und selbst wenn die Schnittstelle eine modifizierbare Datenstruktur referenzieren w\u00fcrde, w\u00fcrde jeder Nutzer des Container-Bausteins von den Ver\u00e4nderungen betroffen sein. Da es keinen Zustand gibt, existieren auch f\u00fcr Schnittstellen keine Konstruktoren und folglich auch nicht f\u00fcr solche Bausteine. Denn wo es keinen Zustand gibt, gib es nichts zu initialisieren. Wenn eine Default-Methode einen Zustand ben\u00f6tigt, m\u00fcssen sie selbst diesen Zustand erfragen. Wie das geht zeigt folgendes Beispiel.<\/p>\n Repr\u00e4sentiert eine Klasse eine Menge von Objekten, die sich sortieren lassen k\u00f6nnen, k\u00f6nnen wir einen Baustein Sortable mit einer Methode sort() realisieren. Allerdings muss die Implementierung irgendwie an die Daten kommen und hier kommt der Trick ins Spiel: Zwar ist sort() eine Default-Methode, doch die erweiterte Schnittstelle besitzt Methoden, die die Klasse implementieren muss, die dem Sortierer die Daten geben. Im Quellcode sieht das so aus:<\/p>\n Teil 1:<\/p>\n import java.util.*;<\/p>\n interface Sortable<T extends Comparable> {<\/p>\n T[] getValues();<\/p>\n void setValues( T[] values );<\/p>\n default void sort() {<\/p>\n T[] values = getValues();<\/p>\n Arrays.sort( values );<\/p>\n setValues( values );<\/p>\n };<\/p>\n }<\/p>\n Damit sort() an die Daten kommt, erwartet Sortable von den implementieren Klassen eine Methode getValues(). Und damit die Daten nach dem Sortieren wieder zur\u00fcckgeschrieben werden k\u00f6nnen, eine zweite Methode setValues(\u2026). Der Clou ist, das die Klasse, die sp\u00e4ter Sortable realisieren wird, mit den beiden Methoden dem Sortierer Zugriff auf den Daten gew\u00e4hrt \u2013 allerdings auch jedem anderem St\u00fcck Code da die Methoden \u00f6ffentlich sind. Da bleibt ein Geschm\u00e4ckle.<\/p>\n Ein Nutzer vor Sortable soll RandomValues sein; die Klasse erzeugt intern Zufallszahlen.<\/p>\n Teil 2:<\/p>\n class RandomValues implements Sortable<Integer><\/p>\n {<\/p>\n private List<Integer> values = new ArrayList<>();<\/p>\n public RandomValues() {<\/p>\n Random r = new Random();<\/p>\n for ( int i = r.nextInt( 20 ) + 1; i > 0; i– )<\/p>\n values.add( r.nextInt(10000) );<\/p>\n }<\/p>\n @Override public Integer[] getValues() {<\/p>\n return values.toArray( new Integer[values.size()] );<\/p>\n }<\/p>\n @Override public void setValues( Integer[] values ) {<\/p>\n this.values.clear();<\/p>\n Collections.addAll( this.values, values );<\/p>\n }<\/p>\n }<\/p>\n Damit sind die Typen vorbereitet und ein Demo schlie\u00dft das Beispiel ab:<\/p>\n Teil 3:<\/p>\n public class SortableDemo {<\/p>\n public static void main( String[] args ) {<\/p>\n RandomValues r = new RandomValues();<\/p>\n System.out.println( Arrays.toString( r.getValues() ) );<\/p>\n r.sort();<\/p>\n System.out.println( Arrays.toString( r.getValues() ) );<\/p>\n }<\/p>\n }<\/p>\n Aufgerufen kommt auf die Konsole zum Beispiel:<\/p>\n [2732, 4568, 4708, 4302, 4315, 5946, 2004]<\/p>\n [2004, 2732, 4302, 4315, 4568, 4708, 5946]<\/p>\n So interessant diese M\u00f6glichkeit auch ist, ein Problem wurde schon angesprochen: Jede Methode in einer Schnittstelle ist public, ob sie nun eine abstrakte oder Default-Methode ist. Es w\u00e4re sch\u00f6n, wenn die Datenzugriffsmethoden nicht \u00f6ffentlich sein w\u00fcrden, aber das geht nicht.<\/p>\n Wo wir gerade bei der Sichtbarkeit sind. Gibt es im Default-Code Code-Duplizierung, so kann der gemeinsame Code bisher nicht in private Methoden ausgelagert werden, da es private Operationen in Schnittstellen nicht gibt. Allerdings l\u00e4uft gerade ein Test, ob so etwas eingef\u00fchrt werden soll.<\/p>\n Warnung!<\/p>\n Nat\u00fcrlich l\u00e4sst sich mit Rumgetrickse ein Speicherort finden, der Exemplarzust\u00e4nde speichert. Es l\u00e4sst sich zum Beispiel in der Schnittstelle ein Assoziativspeicher referenzieren, der eine this-Instanz mit einem Objekt assoziiert. Ein Container-Baustein, der mit add() Objekte in eine Liste setzt und sie mit iterable() herausgibt, k\u00f6nnte so aussehen:<\/p>\n interface ListContainer<T> {<\/p>\n Map<Object, List<Object>> $ = new HashMap<>();<\/p>\n default void add( T e ) {<\/p>\n if ( ! $.containsKey( this ) )<\/p>\n $.put( this, new ArrayList<Object>() );<\/p>\n $.get( this ).add( e );<\/p>\n }<\/p>\n default public Iterable<T> iterable() {<\/p>\n if ( ! $.containsKey( this ) )<\/p>\n return Collections.emptyList();<\/p>\n return (Iterable<T>) $.get( this );<\/p>\n }<\/p>\n }<\/p>\n Nicht nur die \u00f6ffentliche Konstante $ ist ein Problem, sondern auch, dass es ein gro\u00dfartiges doppeltes Speicherloch ist. Ein Exemplar der Klasse, die diese erweitert Schnittstelle nutzt, kann nicht so einfach entfernt werden, denn in der Sammlung ist noch eine Referenz auf das Objekt, die das Garbage Collection verhindert. Und selbst wenn dieses Objekt weg w\u00e4re, h\u00e4tten wir noch all die referenzierten Kinder der Sammlung in der Map. Und das Problem ist nicht wirklich zu l\u00f6sen, und hier m\u00fcsste tief mit schwachen Referenzen in die Java-Voodoo-Kiste gegriffen werden. Alles in allem, keine gute Idee und Java-Chefentwickler Brian Goetz macht auch klar: \u201ePlease don’t encourage techniques like this. There are a zillion "clever" things you can do in Java, but shouldn’t. We knew it wouldn’t be long before someone suggested this, and we can’t stop you. But please, use your power for good, and not for evil. Teach people to do it right, not to abuse it.\u201d[2]<\/a> Daher: Es ist eine sch\u00f6ne Spielerei, aber Zustand sollte eine Aufgabe der abstrakten Basisklassen oder vom Delegate sein.<\/p>\n Zusammenfassung<\/strong><\/p>\n Was wir in den letzten Beispielen gemacht haben war, ein Standardverhalten in Klassen einzubauen, ohne das dabei der Zugriff auf die einmalige Basisklasse n\u00f6tig war und ohne das die Klasse an Hilfsklassen delegiert. In dieser Arbeitsweise k\u00f6nnen Unterklassen in jedem Fall die Methoden \u00fcberschreiben und spezialisieren. Wie haben es also mit \u00fcblichen Klassen zu tun und mit erweiterten Schnittstellen, die nicht selbst eigenst\u00e4ndige Entit\u00e4ten bilden. In der Praxis wird es immer F\u00e4lle geben, in denen f\u00fcr eine Umsetzung eines Problems entweder eine abstrakte Klasse oder eine erweiterte Schnittstelle in Frage kommt. Wir sollten und dann noch einmal an die Unterschiede erinnern: Eine abstrakten Klasse kann Methoden aller Sichtbarkeiten haben und sie auch final setzen, sodass sie nicht mehr \u00fcberschrieben werden k\u00f6nnen. Eine Schnittstelle dagegen ist mit puren virtuellen und \u00f6ffentlichen Methoden darauf ausgelegt, dass eben die Implementierung \u00fcberschrieben werden kann.<\/p>\n [1]<\/a> Siehe etwa http:\/\/scg.unibe.ch\/archive\/papers\/Scha02aTraitsPlusGlue2002.pdf<\/a>. <\/p>\n [2]<\/a> http:\/\/mail.openjdk.java.net\/pipermail\/lambda-dev\/2012-July\/005166.html<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" Bevor wir zu n\u00e4chsten Punkt kommen, m\u00fcssen wir noch einmal inne halten und uns fragen, was denn das Kernkonzept der objektorientierten Programmierung ist. Wohl ohne zu Z\u00f6gern k\u00f6nnen wir Klassen und Kapselung nennen. Klassen und Klassenbeziehungen das Ger\u00fcst jedes Java-Programms. Schauen wir uns Vererbung noch einmal genauer an, so wissen wir, das Unterklassen Spezialisierungen sind, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","_links_to":"","_links_to_target":""},"categories":[11,66],"tags":[],"class_list":["post-1629","post","type-post","status-publish","format-standard","hentry","category-insel","category-java-8"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/posts\/1629","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/comments?post=1629"}],"version-history":[{"count":0,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/posts\/1629\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/media?parent=1629"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/categories?post=1629"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/tags?post=1629"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n