The document discusses how design patterns from the "Gang of Four" book can be implemented in Kotlin. It provides examples of how common design patterns like Singleton, Builder, Proxy, Iterator, State, Strategy, Deferred Value, Fan Out, and Fan In can be achieved idiomatically in Kotlin using features like objects, functions as first-class citizens, sealed classes, and coroutines. It argues that while the patterns still work in Kotlin, the language often provides better alternatives or builds certain patterns directly into the language itself.

1. Design
Patterns
with
Kotlin
Alexey Soshin, June 2019

2. whoami
● Principal Developer @Wix
● Former Software Architect @Gett
● Author of “Hands-on Design Patterns with Kotlin” book
● StackOverflow junkie, top 2% this year
● Occasional Medium writer
● Currently living in London

3. Intro
● “Design Patterns” by “Gang of Four” book was written back in ‘92. This is the only edition
of the book. All examples in the book are either in C++ or SmallTalk
● Somebody once said that “design patterns are workarounds for shortcomings of
particular language”. But he was fan of Lisp, so we can disregard that saying
● Disclaimer: all your favorite design patterns, including Singleton, will work in Kotlin as-is.
Still, there are often better ways to achieve the same goal

4. Kotlin
● Programming language from JetBrains, authors of IntelliJ IDE
● Runs on JVM (but can also be transpiled into JavaScript or platform native code)
● Still more concise than Java 12
● Typesafe (hi, Groovy!)
● Null-safe
● Pragmatic (hi, Scala!)

5. Singleton
“Ensure a class has only one instance, and provide a global point of access to it.”
public final class Singleton {
private static volatile Singleton instance;
private Singleton() {}
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
In Java:
volatile
synchronized
instance
static
private static

6. Singleton - continued
object Singleton
Taken directly from Scala
CounterSingleton.INSTANCE.increment();
When called from Java, instead of usual .getInstance() uses INSTANCE field
CounterSingleton.increment()
Very concise usage syntax:
In Kotlin:

7. Builder
“Allows constructing complex objects step by step”
ElasticSearch API, for example, just LOVES builders...
client.prepareSearch("documents")
.setQuery(query(dressQuery))
.addSort(RANK_SORT)
.addSort(SEARCHES_SORT)
.get()

8. Builder - continued
In Kotlin, often can be replaced with combination of default parameters and .apply()
function
data class Mail(val to: String,
var title: String = "",
var message: String = "",
var cc: List<String> = listOf(),
var bcc: List<String> = listOf(),
val attachments: List<java.io.File> = listOf()) {
fun message(m: String) = apply {
message = m
} // No need to "return this"
}
val mail = Mail("bill.gates@microsoft.com")
.message("How are you?").apply {
cc = listOf("s.ballmer@microsoft.com")
bcc = listOf("pichais@gmail.com")
}
Less boilerplate, same readability

9. Proxy
“Provides a substitute or placeholder for another object”
Decorator and Proxy have different purposes but
similar structures. Both describe how to provide a
level of indirection to another object, and the
implementations keep a reference to the object to
which they forward requests.
In Kotlin: by keyword is used for such delegation
val image: File by lazy {
println("Fetching image over network")
val f = File.createTempFile("cat", ".jpg")
URL(url).openStream().use {
it.copyTo(BufferedOutputStream(f.outputStream()))
}.also { println("Done fetching") }
f
}

10. Iterator
“Abstracts traversal of data structures in a linear way”
class MyDataStructure<T> implements Iterable<T> { ... }
In Java, this is built-in as Iterable interface
Same will work also in Kotlin
class MyDataStructure<T>: Iterable<T> { ... }

11. Iterator - continued
But in order not to have to implement too many interfaces (Android API, anyone?), you
can use iterator() function instead:
class MyDataStructure<T> {
operator fun iterator() = object: Iterator<T> {
override fun hasNext(): Boolean {
...
}
override fun next(): T {
...
}
}
}
Note the “operator” keyword before the name of the function.

12. State
“Allows an object to alter its behavior when its internal state changes”
sealed class Mood
object Still : Mood() //
class Aggressive(val madnessLevel: Int) : Mood()
object Retreating : Mood()
object Dead : Mood()
Kotlin sealed classes are great for state management
Since all descendants of a sealed class must reside in the same file, you also
avoid lots of small files describing states in your project

13. State - continued
Best feature is that compiler makes sure that you check all states when using
sealed class
override fun seeHero() {
mood = when(mood) {
is Still -> Aggressive(2)
is Aggressive -> Retreating
is Retreating -> Aggressive(1)
// Doesn't compile, when must be exhaustive
}
}
override fun seeHero() {
mood = when(mood) {
is Still -> Aggressive(2)
is Aggressive -> Retreating
is Retreating -> Aggressive(1)
is Dead -> Dead // Better
}
}
You must either specify all conditions, or use else block

14. Strategy
“Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets
the algorithm vary independently from the clients that use it.”
class OurHero {
private var direction = Direction.LEFT
private var x: Int = 42
private var y: Int = 173
// Strategy
var currentWeapon = Weapons.peashooter
val shoot = fun() {
currentWeapon(x, y, direction)
}
}
In Kotlin functions are first class citizens.
If you want to replace a method - replace a method, don’t talk.

15. Strategy - continued
object Weapons {
val peashooter = fun(x: Int, y: Int, direction: Direction) {
// Fly straight
}
val banana = fun(x: Int, y: Int, direction: Direction) {
// Return when you hit screen border
}
val pomegranate = fun(x: Int, y: Int, direction: Direction) {
// Explode when you hit first enemy
}
}
You can encapsulate all available strategies
And replace them at will
val h = OurHero()
h.shoot() // peashooter
h.currentWeapon = Weapons.banana
h.shoot() // banana
This is typesafe (hi, JavaScript!), and you don’t need to implement an interface

16. Deferred value
Not once I’ve heard JavaScript developers state that they don’t need design patterns in
JavaScript.
But Deferred value is one of the concurrent design patterns, and it’s widely used nowadays
Also called Future or Promise
with(GlobalScope) {
val userProfile: Deferred<String> = async {
delay(Random().nextInt(100).toLong())
"Profile"
}
}
val profile: String = userProfile.await()
In Kotlin provided as part of coroutines library:

17. Fan Out
“Deliver message to multiple destinations without halting the process”
Producer
Consumer 1 Consumer 2 Consumer 3
“r” “n” “d”
Used to distribute work
Each message delivered to only one consumer,
semi-randomly
Kotlin coroutine library provides
ReceiveChannel for that purpose
fun CoroutineScope.producer(): ReceiveChannel<String> = produce {
for (i in 1..1_000_000) {
for (c in 'a' .. 'z') {
send(c.toString()) // produce next
}
}
}

18. Fan Out - continued
Consumers can iterate over the channel, until it’s closed
fun CoroutineScope.consumer(id: Int,
channel: ReceiveChannel<String>) = launch {
for (msg in channel) {
println("Processor #$id received $msg")
}
}
Here we distribute work between 4 consumers:
val producer = producer()
val processors = List(4) {
consumer(it, producer)
}
for (p in processors) {
p.join()
}

19. Fan In
Similar to Fan Out pattern, Fan In relies on coroutines library and channels
“Receive messages from multiple sources concurrently”
fun CoroutineScope.collector(): SendChannel<Int> = actor {
for (msg in channel) {
println("Got $msg")
}
}
Multiple producers are able to send to the same channel
fun CoroutineScope.producer(id: Int, channel: SendChannel<Int>) = launch {
repeat(10_000) {
channel.send(id)
}
}

20. Fan In - continued
val collector = collector()
val producers = List(4) {
producer(it, collector)
}
producers.forEach { it.join() }
Multiple producers are able to send to the same channel
Outputs:
...
Got 0
Got 0
Got 1
Got 2
Got 3
Got 0
Got 0
...

21. Summary
● Design patterns are everywhere
● Like any new language (unless it’s Go), Kotlin learns from shortcomings of its
predecessors
● Kotlin has a lot of design patterns built in, as either idioms, language constructs or
extension libraries
● Design patterns are not limited by GoF book

22. References
https://sourcemaking.com/design_patterns
https://refactoring.guru/design-patterns
https://www.amazon.com/Hands-Design-
Patterns-Kotlin-applications-
ebook/dp/B079P7Q5HX

23. Question time
Thanks a lot for attending!
Code: https://github.com/AlexeySoshin/KotlinFanInOutAnimation
Keep in touch:
● https://twitter.com/alexey_soshin
● https://stackoverflow.com/users/5985853/alexey-soshin
● https://github.com/alexeysoshin