Some programming languages provide a feature with the rather strange name \u201cduck typing\u201d. Unfortunately, Java is not one of them. In this post, I am going to briefly explain what duck typing is, and how to achieve at least a similar effect using the method references introduced in Java 8.<\/p>\n\n\n\n
The concept of duck typing is probably best known from JavaScript. The term \u201cduck typing\u201d probably originated in a poem by the American author James Whitcomb Riley<\/a>, which says:<\/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<\/p><\/blockquote>\n\n\n\n What does that have to do with programming? Let us envision a function that expects a duck object as a parameter. In this function, we want to call up the duck\u2019s \u201cquack\u201d method. In many cases, we do not actually care whether the object submitted really is a duck, as long as it has a \u201cquack\u201d method with a corresponding signature. In duck typing, the question \u201cIs it a duck?\u201d is not, in fact, determined by the actual type of the object itself, but rather by the object\u2019s properties.<\/p>\n\n\n\n The AJAX-Funktion von JQuery<\/a> constitutes another, more realistic example. It expects an argument that is an object containing a url value and a success callback (over-simplified; in fact, there are numerous other options in JQuery).<\/p>\n\n\n\n Java does not support duck typing. The method signature has to specify the correct type for each argument. For example, an argument has to implement the \u201cduck\u201d interface. It is not enough for a class to have the same methods that are provided for in the interface; no, it is necessary to actually write implements Duck. The following example, which is based on the JQuery AJAX example, illustrates this:<\/p>\n\n\n\n I defined a Request interface and an implementing class called MyRequest. The getUrl method returns the target address, and our AJAX framework calls the callback method as soon as the response is received. As the ajax method requires an argument of the Request type, I can use an instance of MyRequest without difficulty. If, for example, I have the following class, the situation is entirely different:<\/p>\n\n\n\n Even though this class also has the two required methods with an identical signature, the ajax method would refuse an instance of this class because the class does not implement the Request interface. This can often be very annoying, especially if you cannot modify a given class yourself, i.e. you cannot simply add implements Request, e.g. if it comes from a third-party library.<\/p>\n\n\n\n Some other programming languages handle this differently: Haskell<\/a>, for example, does not have \u201cinterfaces\u201d like Java, but Haskell\u2019s \u201ctypeclasses<\/a>\u201d are more or less equivalent to interfaces. And here you can add types to any typeclass<\/a>. at a later time, irrespective of the type definition. Thus, I could add my OtherRequest type to the Request typeclass without having to modify the source code of OtherRequest. After which, I can use OtherRequest values as parameters for functions that require the Request type.<\/p>\n\n\n\n Let us look at an example:<\/p>\n\n\n\n This defines a Request type class with a getUrl function that receives a specific request and returns a string. Consequently, every data type added to this type class has to provide such a function. Among them is the ajax function that receives a request and returns an IO action. The implementation shown here is merely a placeholder that does not actually execute an AJAX request, but only displays the URL in the command line. For this purpose, it can use the getUrl function because the latter has been defined in the type class. Thus, this corresponds to our AJAX library code.<\/p>\n\n\n\n In our program, we can now define our own data type for our request. In order to be able to use the AJAX framework, we have to add our data type to the \u201cRequest\u201d type class:<\/p>\n\n\n\n The data keyword is used to define a new type in Haskell, which in our case is called \u201cOtherRequest\u201d and has a \u201curl\u201d string. With this, Haskell generates a \u201curl\u201d function with the signature OtherRequest -> String, i.e. it receives an OtherRequest value and returns a string.<\/p>\n\n\n\n Instance adds our type to the type class. The line \u201cgetUrl = url\u201d means that the \u201curl\u201d function of our type is to be used if \u201cgetUrl\u201d is called by the type class. We could also specify a different implementation at this point. This is similar to the situation in Java, where a method prescribed by an interface is implemented in a class.<\/p>\n\n\n\n The end of the code segment shows how we can use this. We create an \u201cOtherRequest\u201d value and label it \u201cx\u201d. Then, the \u201cajax\u201d function is called with x as an argument. Since we have added \u201cOtherRequest\u201d to the \u201cRequest\u201d type class, this call works as expected.<\/p>\n\n\n\n As Haskell is not an object-oriented language, this is not completely equivalent to Java. But the important point is that defining our type and adding it to the type class (i.e. implementing the interface) are two independent processes that can be executed in independent sections of the code. Even if the \u201cOtherRequest\u201d type came from a third-party library, we could still add it to the type class we need in order to be able to use it for our program. Therefore, this option is a good substitute for duck typing in terms of extensibility, in particular because it is even possible to abstract from the specific name (see \u201cgetUrl = url\u201d).<\/p>\n\n\n\n Duck typing is usually primarily mentioned in connection with dynamically typed languages such as JavaScript. With those, objects are checked for the necessary methods and attributes at runtime. But duck typing is also possible with static typing. In that case, the verification of whether an object \u201cis a duck\u201d is done at the compile time. Typescript<\/a> is a good example. Our Request example above could look like this in TypeScript:<\/p>\n\n\n\n The ajax function expects an argument of the Request interface type. However, the compiler will also accept an instance of OtherRequest, even though this class does not expressly implement the interface\u2014the fact that all the methods with the correct signature exist is sufficient. You can test the code live here<\/a>.<\/p>\n\n\n\n Back to Java. As mentioned above, Java does not support duck typing. However, using the method references in Java 8 can achieve a similar effect that can be very useful in certain situations, even if it is less elegant. Especially if the class to be used cannot or is not supposed to be modified.<\/p>\n\n\n\n The idea is to not only pass the object to a function, but also to specify how the function can get the necessary methods of the object. Let us look at the AJAX example again:<\/p>\n\n\n\n If you do not have much experience with the functional classes and interfaces of Java 8, the signature of the second overloaded ajax method may take some getting used to for you. First, the method defines a generic type parameter T without specifying any type limits. Consequently, any desired instance can be submitted as the first argument, provided that the functions submitted as the second and third argument match this type. The second argument is a function that returns a string (namely the URL) for a given object of the type T. The third argument submitted is a BiConsumer<\/em>, i.e. a function that accepts two arguments (the Request object and the result string again) and does not have a return value. With lambdas, this function can now be called as follows:<\/p>\n\n\n\n Method references make it more legible:<\/p>\n\n\n\n The line reads like this: Take this Request object. To get the URL, call the getUrl method on the Request object. To process the result, please call the callback method on the object. This approach is not duck typing, but you can use it in situations where you would otherwise wish to use duck typing. In a sense, the method signature expresses requirements for a given object that have to be supported by the object. The fact that the actual name of the methods does not matter with this option is another interesting aspect. OtherRequest could just as well have called its callback method \u201cCallMe_Now\u201d. Incidentally, we could also have done the ajax signature differently in this case:<\/p>\n\n\n\n In this case, we directly submit a function for obtaining the URL and a function for processing the result. From the perspective of the ajax function, it does not matter whether there is a Request object or what type it is. What matters is the difference when calling the method: The method references in this case refer to the otherRequest instance (with a lower case initial), whereas in the example above, the method references referred to the class (OtherRequest with an upper case initial). From an API design point of view, this is the best alternative because the ajax method makes the least assumptions regarding the requester, which makes it highly composable. Nevertheless, there are situations where the \u201cquasi-duck typing\u201d option described above is necessary, and where you really want to receive objects as parameters. For example, we used this option when we developed the Model-Wrapper<\/a>, which is a part of mvvmFX<\/a>, in order to make the getter and setter methods of a wrapped object known.<\/p>\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 of 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\nDynamic or static typing<\/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