The facade allows you to hide the details of the module from clients. It ensures compliance with `Law Demeter`. Using the generic interface and various implementations greatly simplifies testing. It blends well with other patterns like `Strategy`,` Template Method`, or construction patterns, allowing configuration of the object available for the clients. The facade is a good entry point for libraries, giving customers access to high-level functionality and hiding all internal logic and classes.
The `Strategy` pattern creates a family of algorithms, enclosing the differing logic in separate classes while hiding it from clients behind the interface. It enables the interchangeable use of implementations. The use of the strategy simplifies the customer code, avoids code duplication and conditional statements. Significantly simplifies testing - by separating client testing from strategy algorithms.
The template method is a very simple design pattern, that separates shared class parts from changing ones. The core idea is to have an abstract parent class containing the algorithm steps and allowing inheriting classes to overwrite individual steps, but not the algorithm that uses those steps itself.
The factory of factories, 'Abstract Factory' makes creating objects that are part of some 'family' easy. It is another layer over concrete factories delivering client the factory instance for creating objects of a certain variant.
After the `Static Factory Method` it's time for classic `Factory`. Factory is very useful and often used construction design pattern. Kotlin has interesting advantage thanks to `sealed` and `internal` classes, that are missing in Java.
`Static Factory Methods` known from Java have their place also in Kotlin, although they look and behave a bit different because there is no `static` word in Kotlin. Here I'll try to show how to use `companion object` for `Static Factory Methods` and more. PS: This whole post was supposed to be about `Factory Method` with just a short mention about static factory methods, but the topic becomes more interesting than I thought :)
The Builder Design Pattern is one of most popular and useful construction patterns in software engineering. In this post I will try to explain it and show how you can use it with Kotlin. Sadly I often see implementations that are simple translation from Java rather that utilizing cool Kotlin syntactic sugar.
This is not a list of 'golden rules' of code review, there are many blogposts about it. Here I just try to perform retrospective my own experiences.
Deploy Jekyll blog (like this one) on GitHub is very easy. Unless, you want to use not whitelisted plugins... but it't still doable.
I'm using a few computers (and few OS-es) where I run IntelliJ Idea and Android Studio, and keeping their settings the same way everywhere was always a bit painful. Until today when I learned about `settings repository` thing!