Forem: Lovis

Gang of Four Patterns in Kotlin - Slight Return

Lovis — Wed, 30 Aug 2017 13:56:54 +0000

A lot of people read my article Gang of Four Patterns in Kotlin. I honestly didn't expect so much resonance. It was featured, retweeted and discussed. While writing this, the github repository has received more than 100 stars. Thank you all for that! 🙌

With this article, I want to address the most discussed patterns once again: the Decorator and the Builder.
Additionally I want to add an example of Kotlin implementation for an important pattern that was missing from the repository so far: the Visitor.

Decorator

The Decorator pattern as demonstrated in GoF is just a very convoluted way to achieve functions composition

This is what Mario Fusco left me in the comments. What should I say? I think he's correct.
I did not want to use the same solutions Mario used in his repository, so I fell back to a "pure" Kotlin approach. However, funKTionale, a library that adds a lot of "standard" functional patterns to Kotlin, shows that function composition is actually possible with Kotlin, and nothing less "pure" than using extension functions.

Here is the same old decorator example, but this time with function composition:

fun ((String) -> String).then(f: (String) -> String): (String) -> String {
    return { t -> f(this(t)) }
}

There is a lot going on here. (String) -> String.then means that a function then is added to all functions that take a String and return a String. That means that then is an extension function to a function.
The interesting part here is that then also takes the same type of function as a parameter that it extends; and that it also returns the same type of function.
It's therefore possible to write something like this:

val compose: (String) -> String = { string: String -> "$string?" }.then { string: String -> string.replace('c', 'k') }

println(compose("functional")) // will print "funktional?"

It simply chains the function calls together, first adding a ? to the original value and then replacing all c with k.

It's possible to clean this up a little by using the infix modifier. An infix function is a function that can be accessed without brackets or dots.
One example is Kotlin's built-in to function, that creates a Pair:

val pair = "key".to("value") // this is possible
val pair = "key" to "value" // but this is nicer. it works thanks to infix

Applying the infix modifier to the then function results in the following code:

infix fun ((String) -> String).then(f: (String) -> String): (String) -> String { ... }
...
val compose = { ... } then { ... }

To make this example a little bit more similar to the old one, I introduce another infix extension function:

infix fun String.decorate(f: (String) -> String): Text {
    return DefaultText(f(this))
}

This function, decorate is an extension function to String that constructs a DefaultText object with the result of the function f.
I am now actually decorating Strings and not the Text objects anymore, but the result is the same.

With these two extension functions, I can now create and draw a decorated Text like this:

 fun underline(text: String) = "_${text}_"
 fun background(text: String) = "\u001B[43m$text\u001B[0m"

 val text = "Functional" decorate (::underline then ::background)

 text.draw()

The then function composes the underline with the background function. I use function references here, (::) but lambdas would also work.
This is very specific example of function composition, and if I would refactor and generalize it, It will eventually be the same as the composition from the funKTionale library:

infix fun <P1, IP, R> ((P1) -> IP).andThen(f: (IP) -> R): (P1) -> R = { p1: P1 -> f(this(p1)) }

Builder

Some people have noted that my example of the Builder wasn't really idiomatic, since you could simply use constructors with named arguments.
I do agree with that statement, but not under all circumstances.
My example was simple; a Car class with two parameters.

class Car() {
    var color: String = "red"
    var doors = 3

    override fun toString() = "$color car with $doors doors"
}

But that's already the problem. It's too simple. You can easily (and more idiomatically) write it with constructor parameters:

class Car(var color = "red", var doors = 3) {
    override fun toString() = "$color car with $doors doors"
}

//called e.g. like this:
val car1 = Car(color="green")
val car2 = Car(doors=4, color="blue")
val car3 = Car()

That's a nice pattern. And it can definitely replace the Builder pattern for simple examples. But what if you have more properties? It can become quite ugly. Apart from visuals, I'd say that a class with more than 5 constructor parameters is almost always a bad idea, since it's likely doing too many things (unless it's all data).
Another drawback with this approach is, that I can't reuse and pass around the configuration. With apply, I can prepare a car configuration like this:

val config: Car.() -> Unit = {
    color = "yellow"
    doors = 5
}

and apply it later by using Car().apply(config). I could also apply multiple configurations at once, which can make the code a lot more readable than having dozens of constructor parameters.

val car = Car()
           .apply(COBALT_BLUE)
           .apply(LEATHER_PACKAGE)
           .apply(TIRES_18_INCH)

So in order to stay flexible, I still prefer the apply approach in most cases, but the constructor approach is equally useful and valid.

Visitor

Represent an operation to be performed on the elements of an object structure.
Visitor lets you define a new operation without changing the classes of the elements on which it operates

When I want to provide a set of unrelated algorithms that operate on the same elements, a Visitor can be the solution. The difference with e.g. the Strategy is, that the operation that gets executed depends on two types: the type of the Visitor and the type of the element it "visits". This is called double-dispatch. And this is the key to this pattern. Instead of adding a lot of methods to the elements, and therefore statically binding all possible functionality to them, elements will just declare a method accept, that basically says "please operate on me" and make use of one of OOP's most important concepts - dynamic binding.

This has some implications, though. While it's easy to add new operations, it's pretty hard to add new classes to the element hierarchy. For every new class in the hierarchy every Visitor needs to implement a new method.

A visitor and its corresponding elements may look like this:

interface ShapeVisitor<T> {
  T visit(Square element);
  T visit(Circle element);
  T visit(Rectangle element);
  // ... and another `visit` method for every element of the hierarchy
}
interface Shape {
   <T> T accept(ShapeVisitor<T> visitor);
}

(I stole Mario Fusco's example this time. I feel no shame!)

There is one method for every subtype of Shape and one method in each shape to accept an algorithm. A concrete visitor might look like this:

public static class AreaVisitor implements ShapeVisitor<Double> {
        public Double visit(Square element) {
            return element.side * element.side;
        }

        public Double visit(Circle element) {
            return Math.PI * element.radius * element.radius;
        }

        public Double visit(Rectangle element) {
            return element.height * element.width;
        }
    }

And would be called like this:

 double totalArea = 0.0;
 ShapeVisitor<Double> areaVisitor = new AreaVisitor();
 for (Shape figure : figures) {
    totalArea += figure.accept(areaVisitor);
 }
 System.out.println("Total area = " + totalArea);

To add another operation, I can simply add another Visitor

public static class PerimeterVisitor implements ShapeVisitor<Double> {
        public Double visit(Square element) {
            return 4 * element.side;
        }

        public Double visit(Circle element) {
            return 2 * Math.PI * element.radius;
        }

        public Double visit(Rectangle element) {
            return (2 * element.height + 2 * element.width);
        }
    }

As others have pointed out already, it's just a complicated way to do a switch statement over the class of an object. Java does not have a switch on class hierarchies. This is considered anti-oop anyway. So we use the visitor pattern.
Functional programming has a better way of doing things like this: Pattern Matching.

Luckily, Kotlin is a multi-paradigm language so we don't need to be purely object-oriented. And also luckily, Kotlin has Pattern Matching "light" with the when expression and sealed classes.

sealed class Shape()
class Square(val side: Double) : Shape()
class Circle(val radius: Double) : Shape()
class Rectangle(val width: Double, val height: Double) : Shape()

The benefit of sealed classes are that - unlike interfaces or abstract classes -
the compiler knows every possible manifestation of that class. It's therefore possible to use a when expression that checks whether all possible subclasses have been checked:

 val areaVisitor = { shape: Shape ->
        when (shape) {
            is Rectangle -> shape.height * shape.width
            is Circle -> shape.radius.square() * Math.PI
            is Square -> shape.side.square()
        }
    }

If I'd remove e.g. the line is Square -> ... the code wouldn't compile (this is similar to how an enum would behave. Also notice the usage of smart casts, that allow accessing properties of subclasses (e.g. radius or side) without explicit casting.

Now, I can just use that lambda-visitor to sum up all areas.

 val totalArea = figures.sumByDouble { areaVisitor(it) }
 println("Total area = $totalArea")

Adding a new Visitor is also easy, just define a new lambda.

val perimeterVisitor = { shape: Shape ->
        when (shape) {
            is Rectangle -> 2 * shape.height + 2 * shape.width
            is Circle -> 2 * Math.PI * shape.radius
            is Square -> 4 * shape.side
        }
    }

Even more things are possible with the when statement, e.g. an else branch or sharing the same operation for multiple conditions.
For more info, I suggest to check out the documentation on when and sealed classes.

I added the new examples in full length to the github repository. 💥

^{The cover image was taken from stocksnap.io}

Gang of Four Patterns in Kotlin

Lovis — Thu, 01 Jun 2017 17:48:12 +0000

Kotlin is getting more and more relevant. How would common design patterns implemented in Kotlin look like?
Inspired by Mario Fusco's Talk/Blog posts/Repository "From GoF to lambda", I decided to implement some of the most famous design patterns in computer science in Kotlin!

The goal is not to simply implement the patterns, though. Since Kotlin supports object oriented programming and is interoperable with Java, I could just copy-auto-convert every java class in Mario's repository (doesn't matter whether it's the "traditional" or the "lambda" examples) and it would still work!
It's also important to note that these patterns where discovered to overcome the shortcomings of how imperative programming languages were designed in the 90s (C++ in particular). Many modern languages provide features to overcome these issues without writing extra code or falling back to patterns.

That's why —just like Mario in the g ∘ f repository— I will try to find a simpler, easier or more idiomatic way to solve the same problem each pattern is solving.

If you don't like reading explanations, you can directly jump to my github repository

As you might know, there are three types of (gof) patterns: structural, creational and behavioral patterns.
First up are the structural patterns. This is tough, because structural patterns are about - structure! How could I implement a structure with a different structure? I can't. An exception is the Decorator. While it's technically just about structure, its usage is more about behavior or responsibilities.

Structural Patterns

Decorator

Attach additional responsibilities to an object dynamically

Let's say I want to decorate a class Text with some text effects:

class Text(val text: String) {
    fun draw() = print(text)
}

If you know the pattern, you also know that a set of classes has to be created in order to "decorate" (that is extending the behavior) the Text class.
These extra classes can be avoided in Kotlin by using extension functions:

fun Text.underline(decorated: Text.() -> Unit) {
    print("_")
    this.decorated()
    print("_")
}

fun Text.background(decorated: Text.() -> Unit) {
    print("\u001B[43m")
    this.decorated()
    print("\u001B[0m")
}

With these extension functions, I can now create a new Text and decorate its draw method without creating other classes:

Text("Hello").run {
    background {
        underline {
            draw()
        }
    }
}

If you run this from the command line, you will see the text "_Hello_" with colored background (if your terminal supports ansi colors).
Compared to the original Decorator pattern, there is one drawback: I can not pass "pre-decorated" objects around, since there is no Decorator class anymore.
To solve this I can use functions again. Functions are first-class citizens in Kotlin, so I can pass those around instead.

fun preDecorated(decorated: Text.() -> Unit): Text.() -> Unit {
    return { background { underline { decorated() } } }
}

Creational

Builder

Separate the construction of a complex object from its representation so that the same construction process can create different representations

The Builder pattern is really useful. I can avoid variable-heavy constructors and easily re-use predefined setups. Kotlin supports this pattern out of the box with the apply extension function.
Consider a class Car:

class Car() {
    var color: String = "red"
    var doors = 3
}

Instead of creating a separate CarBuilder for this class, I can now use the apply (also works as well) extension to initialize the car:

Car().apply {
    color = "yellow"
    doors = 5
}

Since functions can be stored in a variable, this initialization could also be stored in a variable. This way, I can have pre-configured Builder-functions, e.g. val yellowCar: Car.() -> Unit = { color = "yellow" }

Prototype

Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype

In Java, prototyping could theoretically be implemented using the Cloneable interface and Object.clone(). However, clone is broken, so we should avoid it.
Kotlin fixes this with data classes.
When I use data classes, I get equals, hashCode, toString and copy for free. By using copy, it's possible to clone the whole object and optionally change some of the new object's properties.

data class EMail(var recipient: String, var subject: String?, var message: String?)
...

val mail = EMail("abc@example.com", "Hello", "Don't know what to write.")

val copy = mail.copy(recipient = "other@example.com")

println("Email1 goes to " + mail.recipient + " with subject " + mail.subject)
println("Email2 goes to " + copy.recipient + " with subject " + copy.subject)

Singleton

Ensure a class only has one instance, and provide a global point of access to it

Although the Singleton is considered an anti-pattern these days, it has its usages (I won't discuss this topic here, just use it with caution).
Creating a Singleton in Java needs a lot of ceremony, but Kotlin makes it easy with object declarations.

object Dictionary {
    private val definitions = mutableMapOf<String, String>

    fun addDefinition(word: String, definition: String) {
        definitions.put(word.toLowerCase(), definition)
    }

    fun getDefinition(word: String): String {
        return definitions[word.toLowerCase()] ?: ""
    }
}

Using the object keyword here will automatically create a class Dictionary and a single instance of it. The instance is created lazily, so it's not created until it is actually used.
The object is accessed like static functions in java:

val word = "kotlin"
Dictionary.addDefinition(word, "an awesome programming language created by JetBrains")
println(word + " is " + Dictionary.getDefinition(word))

Behavioral

Template Method

Define the skeleton of an algorithm in an operation, deferring some steps to subclasses

This pattern makes use of class hierarchies as well. You define an abstract method and call it somewhere inside the base class. The implementation is handled by the subclasses.

//java
public abstract class Task {
        protected abstract void work();
        public void execute(){
            beforeWork();
            work();
            afterWork();
        }
    }

I could now derive a concrete Task, that actually does something in work.
Similar to how the Decorator example uses extension functions, my Template Method approach uses a top-level function.

//kotlin
fun execute(task: () -> Unit) {
    val startTime = System.currentTimeMillis() //"beforeWork()"
    task()
    println("Work took ${System.currentTimeMillis() - startTime} millis") //"afterWork()"
}

...
//usage:
execute {
    println("I'm working here!")
}

As you can see, there is no need to have a class at all! One could argue, that this now resembles the Strategy pattern, which is probably correct. But then again, Strategy and Template Method are solving very similar problems (if not the same).

Strategy

Define a family of algorithms, encapsulate each one, and make them interchangeable

Let's say I have a Customer that pays a certain fee per month. This fee can be discounted. Instead of having a subclass of Customer for each discounting-strategy, I use the Strategy pattern.

class Customer(val name: String, val fee: Double, val discount: (Double) -> Double) {
    fun pricePerMonth(): Double {
        return discount(fee)
    }
}

Notice that I'm using a function (Double) -> Double instead of an interface for the strategy. To make this more domain-specific, I could also declare a type alias, without losing the flexibility of an higher-order-function: typealias Discount = (Double) -> Double.
Either way, I can define multiple strategies for calculating the discount.

val studentDiscount = { fee: Double -> fee/2 }
val noDiscount = { fee: Double -> fee }
...

val student = Customer("Ned", 10.0, studentDiscount)
val regular = Customer("John", 10.0, noDiscount)

println("${student.name} pays %.2f per month".format(student.pricePerMonth()))
println("${regular.name} pays %.2f per month".format(regular.pricePerMonth()))

Iterator

Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

Writing an Iterator is a rare task. Most of the time, it's easier and more convenient to wrap a List and implement the Iterable interface.
In Kotlin, iterator() is an operator function. This means that when a class defines a function operator fun iterator(), it can be iterated using a for loop (no interface needed). That's particularly cool because it works also with extension functions. That's right - by using an extension function, I can make every object iterable. Consider this example:

class Sentence(val words: List<String>)
...
operator fun Sentence.iterator(): Iterator<String> = words.iterator()

I can now iterate over a Sentence. This also works if I'm not the owner of the class.

More patterns

I mentioned a few patterns, but those are not all Gang of Four patterns. As I said in the introduction, especially the structural patterns are hard or impossible to write in a different way than in Java. Some other patterns can be found in the repository. I'm open for feedback and pull-requests ☺.

I hope this post gave you an idea on how Kotlin can result in different approaches to well known problems.

Make sure to check out the second part of this post: Gang of Four Patterns in Kotlin - Slight Return

One last thing I want to mention is, that the java-to-kotlin ratio in the repository is ~⅓ Kotlin and ~⅔ Java, although both versions do the same thing 🙃

^{The cover image was taken from stocksnap.io}

Kotlin on Android: Not a big surprise, actually

Lovis — Fri, 19 May 2017 18:52:02 +0000

Google finally announced first-class Kotlin support for Android! ðŸŽ‰ðŸ¾ðŸŽŠ
Some of us knew that this would happen one day and we can now safely say "Told ya!".¹

However, not all people were so sure about this.

It was last year around April, when a co-worker posted an article in our company's Slack that "Google is said to be considering Swift as a â€˜first class’ language for Android".
I was curious, so I immediately read the article. Not only was I curious, but I was also skeptical. It turned out, I was right to be.

While Swift is definitely a great language, something felt off. I thought "why not Kotlin?".
Those of us who were already playing with Kotlin, or even used it in production, knew of the benefits and it's ease of use.

Despite the article's title, the article quickly got to the point where it stated that using swift was actually too complicated:

"Android would need a runtime for Swift"

"Google would also have to make its entire standard library Swift-ready"

"Swift would also not be useful in bridging higher level APIs in Java"

So my suspicion is that the author picked "Swift" for the headline because it would generate more clicks than "Google considers other languages than Java".

Some of my co-workers (iOS developers, obviously ðŸ˜‰), where sold anyway:

"I saw a talk at the local cocoa heads. The guy showed us how to run Swift on Android."
"Oh, that's interesting. How did he do it?"
"I don't really know, I think something with native bindings"
"He used the NDK? That's not really convenient, isn't it? It's also kinda slow."
"Maybe but you can now use Swift on Android! So we only write our model once and use it everywhere! Also, when Foundation is ready, you won't even need Retrofit and these things anymore!!!!111!"
"Dude, du you even know what Retrofit is? Also, Kotlin has more or less the same features as Swift, but works out of the box..."
"Doesn't matter, Swift is better!"

Ok, maybe I'm exaggerating here and the conversation was actually more civilized, but that's what it has become in my memory ðŸ˜œ.
The point is, even back then, Kotlin was already the better choice for Android.
Kotlin has always been developed with Android in mind. In my opinion, it was made for Android development:

It compiles to Java 6 compatible bytecode
It's 100% inter-operable with existing Android- and Java- APIs
The Android framework relies heavily on null - and Kotlin makes dealing with it more safe.
Delegates like lazy or the lateinit-keyword make it more comfortable to work with e.g. the Android Resources class.
Lambdas can be inlined to gain performance.
Extension functions help us add functionality to Android framework classes without reflection or subclassing.
Extension functions are resolved statically, which may also benefit performance.
The Kotlin runtime is (compared to how powerful it is) really small - only about 7000 methods and 1MB.
Dagger, Butterknife, Android Databinding and other libraries commonly used by Android developers run smoothly with little extra configuration.
A lot of libraries are already taking Kotlin into Account (or were made for Kotlin), e.g. Rx Binding or Anko
You don't need to choose between Java and Kotlin - you can use both in the same project!

The article continues with arguments of why Kotlin is probably not going to be Google's language of choice.

Well actually, the only argument against Kotlin the article mentions is "that Google’s current mindset is that Kotlin is a bit too slow when compiling.". Which sounded ridiculous to me: at that time our Android team had build times of 2 minutes at max, while iOS struggled to get their build times below 15 minutes.

The other "argument" seems like plain ignorance to me:

Though Kotlin is an alternative, it’s a very nascent language without the eager community Swift has.

I have no idea how anybody who ever took a glimpse at Kotlin could call it "nascent"² (if the author actually used it, it's even more weird to write something like this), especially if you consider that it was already in 1.0 for more than a month during the time the article was published.
The point with the community might be true though, but I doubt that Swift's community would be as eager if Apple wouldn't embrace Swift themselves.

Swift is a really nice language, but it's not the right choice for Android development.

At Google i/o 2017, Google took the right step by making Kotlin an officially supported language of the Android platform.
Every CTO who feared the adoption of Kotlin for Android can now rest assured: your developers knew what they were doing.

The surprise isn't that Kotlin is now officially supported, the actual surprise was that it took so long for Google to embrace it.

¹ I originally drafted this article as "Swift on Android is not gonna happen", but then Google i/o crossed my plans ðŸ˜…. This post is not supposed to be a rant or show how great I am because I anticipated this. It should simply highlight why Kotlin is the better option.

² I understand "nascent" as in "too small to be taken serious" here, because it's used as an argument against Kotlin.

The cover image was created with the JetBrains Artwork creator

Hi, I'm Lovis

Lovis — Tue, 14 Mar 2017 09:48:17 +0000

I'm Lovis from Hamburg (Germany). ðŸˆ

In the past 5 years I've mostly been doing Android development. Thus¹, Kotlin ðŸ’™!

I'm also interested in Architecture, Extreme Programming, Agile an the like. Always try to uncover new ways of thinking and solving problems.

The truth is, I came here for the stickers.

¹ I found a way to use thus on the internet! ðŸ‘Š