Einige Programmiersprachen bieten ein Feature mit dem etwas eigenartigen Namen \u201cDucktyping\u201d. Java z\u00e4hlt leider nicht dazu. In diesem Artikel m\u00f6chte ich kurz erkl\u00e4ren, was Ducktyping ist und wie man mit den in Java 8 eingef\u00fchrten Methodenreferenzen zumindest einen \u00e4hnlichen Effekt erzielen kann.<\/p>\n\n\n\n
Am bekanntesten ist das Konzept von Ducktyping vermutlich aus JavaScript. Der Begriff \u201cDucktyping\u201d geht wohl auf ein Gedicht des amerikanischen Schriftstellers James Whitcomb Riley<\/a> zur\u00fcck, worin es hei\u00dft:<\/p>\n\n\n\n \u201cWhen I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.\u201d Wie passt das mit Programmierung zusammen? Stellen wir uns vor wir haben eine Funktion, die ein Enten-Objekt als Parameter erwartet. In der Funktion wollen wir die \u201cschnattern\u201d-Methode der Ente aufrufen. Ob es sich bei dem \u00fcbergebenen Objekt aber wirklich um eine Ente handelt, kann uns in vielen F\u00e4llen eigentlich herzlich egal sein \u2013 Hauptsache es besitzt eine Methode \u201cschnattern\u201d mit der passenden Signatur. Bei Ducktyping wird also die Frage \u201cIst es eine Ente?\u201d nicht am tats\u00e4chlichen Typ des Objekts festgemacht, sondern an den Eigenschaften, die das Objekt besitzt.<\/p>\n\n\n\n Ein anderes, realeres Beispiel ist die AJAX-Funktion von JQuery<\/a>. Diese erwartet als Argument ein Objekt, welches einen url-Wert und einen success-Callback enth\u00e4lt (Stark vereinfacht. Tats\u00e4chlich gibt es noch zahlreiche weitere Varianten bei JQuery).<\/p>\n\n\n\n Java unterst\u00fctzt kein Ducktyping. In der Methodensignatur muss f\u00fcr jedes Argument der richtige Typ angegeben werden. Ein Argument muss also beispielsweise das \u201cEnte\u201d-Interface implementieren. Es reicht nicht, dass eine Klasse die gleichen Methoden besitzt, die im Interface vorgesehen sind, nein es muss auch wirklich implements Ente geschrieben werden. Folgendes Beispiel, in Anlehnung an das JQuery-AJAX-Beispiel, soll das verdeutlichen:<\/p>\n\n\n\n Ich habe ein Interface Request definiert und eine implementierende Klasse MyRequest. Die Methode getUrl gibt die Ziel-Adresse zur\u00fcck und die callback-Methode wird von unserem AJAX-Framework aufgerufen, sobald die Antwort eingetroffen ist. Da die ajax-Methode ein Argument vom Typ Request verlangt, kann ich ohne Probleme eine Instanz von MyRequest benutzen. Habe ich aber beispielsweise folgende Klasse, sieht die Sache ganz anders aus:<\/p>\n\n\n\n Obwohl diese Klasse ebenfalls die beiden ben\u00f6tigten Methoden mit der identischen Signatur besitzt, w\u00fcrde die ajax-Methode eine Instanz dieser Klasse verweigern, da die Klasse das nicht das Interface Request implementiert. Das kann oft \u00e4rgerlich sein, vor allem, wenn man eine gegebene Klasse nicht einfach selbst ver\u00e4ndern kann, also nicht einfach implements Request dran schreiben kann, beispielsweise wenn diese aus einer Drittbibliothek stammt.<\/p>\n\n\n\n Bei anderen Programmiersprachen ist das zum Teil anders: Bei Haskell<\/a> beispielsweise gibt es zwar keine \u201cInterfaces\u201d im Java-Sinne aber man k\u00f6nnte Haskells \u201ctype classes<\/a>\u201d in etwa mit Interfaces vergleichen. Und hier kann man Typen auch unabh\u00e4ngig von der Typdefinition nachtr\u00e4glich zu beliebigen Type-Classes hinzuf\u00fcgen<\/a>. Ich k\u00f6nnte also meinen Typ OtherRequest der Type-Class Request hinzuf\u00fcgen, ohne dass ich den Quellcode von OtherRequest anfassen muss. Anschlie\u00dfend kann ich OtherRequest-Werte als Parameter f\u00fcr Funktionen nutzen, die Request als Typ verlangen.<\/p>\n\n\n\n Schauen wir uns ein Beispiel an:<\/p>\n\n\n\n Hier wird eine Type-Class Request mit einer Funktion getUrl definiert, die einen konkreten Request entgegen nimmt und einen String zur\u00fcck gibt. Jeder Datentyp, der dieser Type-Class hinzugef\u00fcgt wird muss also eine solche Funktion bereitstellen. Darunter befindet sich die ajax-Funktion, die einen Request entgegen nimmt und eine IO-Aktion zur\u00fcck gibt. Die hier gezeigte Implementierung ist nur ein Platzhalter und f\u00fchrt nicht wirklich einen AJAX-Request aus, sondern gibt lediglich die URL auf der Kommandozeile aus. Dazu kann es aber auf die getUrl Funktion zur\u00fcck greifen, da diese ja in der Type-Class definiert wurde. Dies entspricht also unserem AJAX-Library-Code.<\/p>\n\n\n\n In unserem Programm k\u00f6nnten wir nun unseren eigenen Datentyp f\u00fcr unseren Request definieren. Um das AJAX-Framework benutzen zu k\u00f6nnen m\u00fcssen wir unseren Datentyp zur \u201cRequest\u201d-Type-Class hinzuf\u00fcgen:<\/p>\n\n\n\n Mit dem data-Schl\u00fcsselwort wird in Haskell ein neuer Typ definiert, der in unserem Fall \u201cOtherRequest\u201d hei\u00dft und einen String \u201curl\u201d besitzt. Haskell erzeugt damit eine Funktion \u201curl\u201d, mit der Signatur OtherRequest -> String, die also ein OtherRequest-Wert entgegen nimmt und einen String zur\u00fcck gibt.<\/p>\n\n\n\n Mit instance wird unser Typ der Type-Class hinzugef\u00fcgt. Mit der Zeile \u201cgetUrl = url\u201d sagen wir aus, dass die \u201curl\u201d-Funktion unseres Typs benutzt werden soll, wenn \u201cgetUrl\u201d von der Type-Class aufgerufen wird. Wir k\u00f6nnten an der Stelle aber auch eine andere Implementierung angeben. Dies ist also vergleichbar mit der Situation in Java, wo in einer Klasse eine Methode implementiert wird, die durch ein Interface vorgeschrieben wird.<\/p>\n\n\n\n Der untere Teil des Codeausschnitts zeigt, wie wir das ganze benutzen k\u00f6nnen. Wir erstellen einen \u201cOtherRequest\u201d-Wert und weisen ihm den Namen \u201cx\u201d zu. Anschlie\u00dfend wird die \u201cajax\u201d-Funktion mit x als Argument aufgerufen. Da wir \u201cOtherRequest\u201d der Type-Class \u201cRequest\u201d hinzugef\u00fcgt haben, funktioniert dieser Aufruf wie erwartet.<\/p>\n\n\n\n Da Haskell keine objektorientierte Sprache ist, l\u00e4sst sich das ganze nicht komplett mit Java vergleichen. Der springende Punkt ist aber: Die Definition unseres Typs und das Hinzuf\u00fcgen zur Type-Class (also das Implementieren des Interfaces) sind zwei unabh\u00e4ngige Vorg\u00e4nge, die an unabh\u00e4ngigen Stellen im Code durchgef\u00fchrt werden k\u00f6nnen. Der Typ \u201cOtherRequest\u201d h\u00e4tte auch aus einer Dritt-Bibliothek stammen k\u00f6nnen. Trotzdem k\u00f6nnten wir ihn f\u00fcr unser Programm der ben\u00f6tigten Type-Class hinzuf\u00fcgen um ihn benutzen zu k\u00f6nnen. In Punkto Erweiterbarkeit ist diese Variante also ein guter Ersatz f\u00fcr Ducktyping, vorallem da sogar von der konkreten Benennung abstrahiert werden kann (siehe \u201cgetUrl = url\u201d).<\/p>\n\n\n\n Ducktyping wird in der Regel vor allem im Zusammenhang mit dynamisch Typisierten Sprachen wie JavaScript genannt. Bei diesen wird also zur Laufzeit bestimmt, ob ein Objekt die n\u00f6tigen Methoden und Attribute besitzt. Aber auch bei statischer Typisierung ist Ducktyping m\u00f6glich. Die Pr\u00fcfung, ob ein Objekt \u201ceine Ente ist\u201d, findet dann zur Compile-Zeit statt. Ein gutes Beispiel ist Typescript<\/a>. Unser Request-Beispiel von vorhin k\u00f6nnte in Typescript so aussehen:<\/p>\n\n\n\n Die ajax-Funktion erwartet ein Argument vom Interface-Typ Request. Aber auch eine Instanz von OtherRequest wird vom Compiler akzeptiert, obwohl diese Klasse das Interface nicht explizit implementiert \u2013 es reicht, dass alle Methoden mit der korrekten Signatur vorhanden sind. Der Code kann hier<\/a> auch live ausprobiert werden.<\/p>\n\n\n\n Zur\u00fcck zu Java. Wie oben schon erw\u00e4hnt, unterst\u00fctzt Java kein Ducktyping. Mit den Methoden-Referenzen aus Java 8 kann man aber einen \u00e4hnlichen Effekt erzielen, der zwar nicht so elegant, in einigen Situationen aber trotzdem sehr n\u00fctzlich sein kann. Vor allem dann, wenn die zu benutzende Klasse eben nicht ver\u00e4ndert werden kann oder soll.<\/p>\n\n\n\n Die Idee ist, einer Funktion nicht nur das Objekt mitzugeben, sondern auch mitzuteilen, wie die Funktion an die notwendigen Methoden des Objekts herankommen kann. Schauen wir uns das wieder am AJAX-Beispiel an:<\/p>\n\n\n\n Wer bisher noch wenig mit den Funktionalen Klassen und Interfaces von Java 8 zutun hatte, f\u00fcr den sieht die Signatur der zweiten \u00fcberladenen ajax-Methode vielleicht etwas gew\u00f6hnungsbed\u00fcrftig aus. Zun\u00e4chst definiert die Methode einen generischen Typ-Parameter T ohne dabei irgendwelche Typ-Grenzen festzulegen. Es kann folglich jede beliebige Instanz als erstes Argument \u00fcbergeben werden, solange sichergestellt ist, dass die Funktionen, die als zweites und drittes Argument \u00fcbergeben werden, zu diesem Typ passen. Das zweite Argument ist eine Funktion, die f\u00fcr ein gegebenes Objekt vom Typ T einen String (n\u00e4mlich die URL) zur\u00fcck liefert. Als drittes wird ein BiConsumer<\/em> \u00fcbergeben, sprich eine Funktion, die zwei Argumente (wieder das Request-Objekt und den Ergebnis-String) entgegen nimmt und keinen R\u00fcckgabewert hat. Mit Lambdas kann diese Funktion nun so aufgerufen werden:<\/p>\n\n\n\n Besser lesbar wird es mit Methodenreferenzen:<\/p>\n\n\n\n Die Zeile liest sich quasi so: Nimm dieses Request-Objekt. Um an die URL zu gelangen, rufe die getUrl-Methode auf dem Request-Objekt auf. Und zur Verarbeitung des Ergebnisses bitte die callback-Methode auf dem Objekt aufrufen. Dieses Vorgehen ist zwar kein Ducktyping. Aber man kann es in Situationen nutzen, in denen man sich sonst Ducktyping w\u00fcnschen w\u00fcrde. Die Methodensignatur dr\u00fcckt gewisserma\u00dfen Anforderungen an ein gegebenes Objekt aus, die von dem Objekt unterst\u00fctzt werden m\u00fcssen. Interessant dabei ist auch, dass die tats\u00e4chliche Benennung der Methoden bei dieser Variante egal ist. OtherRequest h\u00e4tte seine Callback-Methode auch \u201crufMichAn_Sofort\u201d nennen k\u00f6nnen. \u00dcbrigens h\u00e4tte man im konkreten Fall die Signatur von ajax noch anders gestalten k\u00f6nnen:<\/p>\n\n\n\n Hier wird direkt eine Funktion zum Beschaffen der URL und ein Funktion zum Verarbeiten des Ergebnisses \u00fcbergeben. Aus Sicht der ajax-Funktion spielt es keine Rolle, ob es da ein Request-Objekt gibt und von welchem Typ es ist. Wichtig ist der Unterschied beim Aufruf der Methode: Die Methodenreferenzen beziehen sich hier auf die Instanz otherRequest (mit kleinem Anfangsbuchstaben), w\u00e4hrend im oberen Beispiel die Methodenreferenzen auf die Klasse abzielten (OtherRequest mit gro\u00dfem Anfangsbuchstaben). Aus API-Design-Gesichtspunkten ist diese Variante am besten, da die ajax-Methode die wenigsten Annahmen \u00fcber den Aufrufer anstellt und damit sehr gut komponierbar ist. Es gibt aber Situationen, wo die oben gezeigte \u201cQuasi-Ducktyping\u201d-Variante notwendig ist und man wirklich Objekte als Parameter entgegen nehmen m\u00f6chte. Beispielsweise haben wir bei der Entwicklung des Model-Wrappers<\/a>, der Teil von mvvmFX<\/a> ist, diese Variante benutzt um Getter- und Setter-Methoden eines gewrappten Objekts bekannt zu machen.<\/p>\n\n\n\n
\u201cWenn ich einen Vogel sehe, der l\u00e4uft wie eine Ente und schwimmt wie eine Ente und schnattert wie eine Ente, dann nenne ich diesen Vogel auch Ente.\u201d<\/p><\/blockquote>\n\n\n\n public interface Request {\n String getUrl();\n void callback(String result);\n }\n public class MyRequest implements Request {\n public String getUrl() {\n return \"http:\/\/blog.saxsys.de\";\n }\n public void callback(String result) {\n System.out.println(result);\n }\n }\n public void ajax(Request request) {\n ...\n }<\/code><\/pre>\n\n\n\n public class OtherRequest {\n public getUrl(){\n return \"http:\/\/stage-sgs.dsinet.de\";\n }\n public void callback(String result) {\n System.out.println(result);\n }\n }<\/code><\/pre>\n\n\n\nAd-Hoc-Implementation von Interfaces<\/h2>\n\n\n\n
class Request r where\n getUrl :: r -> String\n ajax :: (Request r) => r -> IO ()\n ajax r = do print $ getUrl r<\/code><\/pre>\n\n\n\n data OtherRequest = OtherRequest {url::String} deriving (Show)\n instance Request OtherRequest where\n getUrl = url\n x = OtherRequest \"http:\/\/www.saxsys.de\"\n ajax x<\/code><\/pre>\n\n\n\nDynamische oder statische Typisierung<\/h2>\n\n\n\n
interface Request {\n getUrl(): string\n callback(result: String)\n }\n class MyRequest implements Request {\n getUrl() {\n return \"http:\/\/example.org\";\n }\n callback(result: String) {\n console.log(result);\n }\n }\n class OtherRequest {\n getUrl() {\n return \"http:\/\/example.org\";\n }\n callback(result: String) {\n console.log(result);\n }\n }\n function ajax(request: Request) {\n }\n var r1 = new MyRequest();\n var r2 = new OtherRequest();\n ajax(r1);\n ajax(r2);<\/code><\/pre>\n\n\n\n public void ajax(Request request) {\n String url = request.getUrl();\n ...\n String result = ...\n request.callback(result);\n }\n public <T> void ajax(T request, Function<T,String> urlExtractor, BiConsumer<T, String> callback) {\n String url = urlExtractor.apply(request);\n ...\n String result = ...;\n callback.accept(request, result);\n }<\/code><\/pre>\n\n\n\n MyOtherRequest myRequest = new MyOtherRequest();\n ajax(myRequest, req -> req.getUrl(), (req, result) - req.callback(result));<\/code><\/pre>\n\n\n\n OtherRequest otherRequest = new OtherRequest();\n ajax(myRequest, OtherRequest::getUrl, OtherRequest::callback);<\/code><\/pre>\n\n\n\n public void ajax(Supplier<String> urlSupplier, Consumer<String> callback) {\n String url = urlSupplier.get();\n ...\n callback.accept(\"das Result\");\n }\n \/\/ Aufruf\n ajax(otherRequest::getUrl, otherRequest::callback);<\/code><\/pre>\n\n\n\n