API design

Scala has popularized the 'Pimp my library' pattern: This is just a fancy expression to refer to the ability to supplement a library using implicit conversions. — Pimp My Library Pattern in Scala Kotlin does provide the same capability. However, it achieves it via extension functions. While the generated bytecode is similar to Java’s static methods, the developer experience is the same as adding functions to existing types. This approach has limitations, though. One cannot

A recent question on Kotlin’s Reddit came to my attention lately: 'Why is it bad to write extension functions for classes that you own?' One of the answer was that it was the opposite: it’s a good practice, and for several reasons. Among them were two very important ones that improve the design of one’s code: Able to call the function on a nullable. For a class with generic types, add a function that is only available when a specific type is used.

Java 8 introduced default methods in interfaces. This post describes what they are, and how they can change the design of APIs. A nominal design Earlier, in Java, interfaces could only have contracts - method signatures with no implementation. In order to add some implementation, a class was required, whether abstract or not. Hence, traditional API design then followed this hierarchy: The root interface defines the contractAn intermediate class implements common behavior i.e. BarIf