Forem: Oluwasanmi Aderibigbe

Learnings from DroidCon Berlin 2021

Oluwasanmi Aderibigbe — Sun, 24 Oct 2021 10:52:00 +0000

I recently attended DroidCon Berlin 2021. I was fortunate enough to be able to attend Droidcon Berlin online last year, but this was my first ever in-person conference. It was a wonderful experience! And I learnt a lot!

There were a lot of great talks spanning different topics from Jetpack Compose to also the shape of media regulation to come. But I'll be giving a summary of some talks I found interesting. Slides and video recordings will be published soon on

Backend For Frontend(BFF)

Backend for frontend was a talk given by Michal Szczepanik. He talked about the BFF pattern. At some point, we might have encountered a situation where API calls to the backend become clunky because the APIs weren't developed with mobile in mind. Maybe the backend was developed solely for the frontend at first. As a mobile dev, you find yourself making multiple API calls and merging them just so you can display the right data on the screen.
The BFF pattern is a pattern that was developed by Soundcloud. They propose instead of building one general API backend that serves mobile, frontend, and external users. You should create multiple API backend for each experience. Experience doesn't outrightly mean platform. For example, if you're trying to set up a BFF system for ride-hailing. You'd have two experiences; the rider and driver experience. If the experience is the same between both IOS and Android, then you can have one BFF for both apps.
I like this approach to building apps because it provides dedicated and solutions for each client. I was also fortunate enough to speak to a mobile lead whose team uses the BFF system. Aside from having more backend devs, he didn't see any disadvantages to using the BFF pattern. In my opinion, if you already have a cross-platform team, then that's also not a disadvantage.
Here's an in-depth article about the BFF system https://samnewman.io/patterns/architectural/bff/

The journey of adopting Jetpack Compose in Babbel’s App

Compose!! This was super fun and existing talk by
Ahmed Mabrook and Benjamin Kadel. They talked about their bitter-sweet but mostly sweet experience adopting Compose. They can be summarised by:

Learn by digging into the source code.
Read the documentation!!
If you need to use existing styles and themes, use the MDC theming adapter library.
No migration was needed with their current MVVM architecture. They only had to migrate from data binding to Compose's State and LiveData. The major takeaway from this talk is migrating to compose isn't going to be as difficult as I thought it would be. Sure switching from an imperative way of building apps to a declarative way might take some getting used to.

Engineering Design System

Luca Nicoletti give an awesome talk on how they engineered their design system.
According to Luca, a design system is a collection of reusable components, guided by clear standards, that can be assembled to build any number of applications. A design system is not just the design, it's code, implementation altogether.
There are many advantages to developing apps using a design system. Some of them include:

Consistency
Improved maintainability
Faster app development after an initial effort to build the design system.
Migrating to a different view system becomes a bit simpler. Developing a design system requires a lot of effort at first. But I believe it's worth it. Especially, when you get to develop multiple apps using the design system. When building a design system, ensure you separate your views from the state. The state should drive your views. This makes migrating to something like Compose simpler. And also strive to make your components atomic and simple.

Offline is not an error

Offline is not error was a very very interesting talk by Yonatan (Yoni) Levin. He talked about how they handle offline first support with the editing of actions in the Monday app. His approach uses something that resembles the Command pattern (in my opinion) to separate operations from the operation executer. This makes it very easy to add support for new operations later in the future. He also uses reactive DB observations and Work manager chains as a queue. Whenever the Work manager modifies the DB, the DB emits a new flow, and the UI changes accordingly. This is just an overview using what I could remember. It involves more moving parts than what I described. It was a very interesting talk. If you need to implement offline support in your apps, I'd suggest checking it out.

The Billion User Open Secret

The Billion User Open Secret was a talk by Abel Adugam A. Nibori. A 20-year-old CEO from Nigeria! He talked about how to build apps for the next billion users. Most of which will come from Africa, Asia, and South America. We should consider making our app size smaller, using less data consumption amongst others. I'd suggest you check it out.

There were a lot of other interesting talks but I wasn't able to jot some things down and I could find a way to clone myself :D. But no worries, the slides, and presentations will be uploaded on Droidcon Berlin soon. I had so much fun and I can't wait to attend Droidcon Berlin 2022. Maybe who knows, I might attend as a speaker next time.

Head First Design Patterns : 10 of 10 ( Proxy Pattern)

Oluwasanmi Aderibigbe — Sun, 12 Sep 2021 12:34:03 +0000

I just learnt a new design from the Head First Design Pattern book. Today, I learnt about the State pattern.

According to The head first design pattern, the Proxy pattern is used to provide a placeholder for another object to control access to it. It also allows you to perform actions before or after calls have been made to the real object.

Types of Proxy:

1 Remote proxy: A remote proxy is a kind of proxy that acts as a local representative of an object that lives in a different JVM. Method calls to a remote proxy are transferred over the wire and invoked, and the result being returned to the proxy and then to the client.

2 Virtual Proxy: A virtual proxy is a kind of proxy that acts as a representative for an object that is expensive to create. Virtual proxies defer the creation of the real object until it is needed.

3 Protection Proxy: A protection proxy is a kind of proxy that is used to restrict access to confirm calls to the real object.

4 Cache Proxy: A cache proxy is a kind of proxy that caches data returned by the real object so later calls to return the cached data.

5 Log Proxy: A Logging proxy is a kind of proxy that is used to logs requests to the real object before or after.

Implementing a proxy is rather simple. Proxy is a wrapper around the real object with the same base type as the real object.

interface Money

class Cash : Money {
  fun makePayment(){ }
}

class ATMCard(val cash: Cash) : Money {
    fun makePayment() {
         if (checkTime()) {
             cash.makePayment()
         } else {
             throw  IllegalArgumentException("You can not use an atm at this time")
         }
    }

    fun checkTime() : Boolean
}

The first thing you need to do is setup up your marker interface or abstract class.
Make the real object and the proxy implement the same type.
Make the proxy wrapper the real object and delegate calls to it.

The example above is a protection proxy. It validates calls to the real object before delegating them to the real object.
This design pattern is somewhat similar to the Decorator design pattern in implementation. The proxy pattern is used to control access to the real object while the Decorator pattern is used to add new behaviour to the object.

Head First Design Patterns : 9 of 10 ( State Pattern)

Oluwasanmi Aderibigbe — Sat, 04 Sep 2021 18:19:50 +0000

I just learnt a new design from the Head First Design Pattern book. Today, I learnt about the State pattern.

According to The Head first design pattern, The State pattern allows an object to alter its behaviour when its internal state changes. The object will appear to change its class. The state pattern achieves this by creating a finite number of state classes for the object and also events that allow the object changes its state. This allows the object to delegate calls to different state classes. In turn, changing the behaviour of the object.

Implementing the state pattern starts with:

Creating your context class. The context class is the class whose behaviour you'd like to change using the State pattern at runtime.
Identifying the different states of your object and also events. Events are actions that changes the state of your object.
Defining an abstract state base. It can be an abstract or a Marker interface.
Create the state classes.

For example, we are going to implement an program that fetches upcoming film titles. To implement this using the state pattern. The first thing we need to do is create our context and identify the different states of the programme and our it transitions from one state to another.

class UpcomingTitlesFetcher {
private var state: State = loadingState
}

UpcomingTitlesFetcher is our context. It holds a reference to the State interface.

The UpcomingTitlesFetcher has four states; Initial, Loading, Success, and Failure.


sealed interface State {
    fun showInitial()
    fun showLoading()
    fun showUpcomingTitles()
    fun showFailure()

    class Initial(val upcomingTitlesFetcher: UpcomingTitlesFetcher) : State {
        init {
            upcomingTitlesFetcher.setState(this)
        }

        override fun showInitial() {
            upcomingTitlesFetcher.setState(Initial(upcomingTitlesFetcher))
        }

        override fun showLoading() {
            upcomingTitlesFetcher.setState(LoadingState(upcomingTitlesFetcher))
        }

        override fun showUpcomingTitles() {
            throw IllegalStateException()
        }

        override fun showFailure() {
            throw IllegalStateException()
        }

    }

    class LoadingState(val upcomingTitlesFetcher: UpcomingTitlesFetcher) : State {
        init {
            upcomingTitlesFetcher.setState(this)
        }

        override fun showInitial() {
            throw IllegalStateException()
        }

        override fun showLoading() {
            upcomingTitlesFetcher.setState(LoadingState(upcomingTitlesFetcher))
        }

        override fun showUpcomingTitles() {
            val titles = getTitles()
            upcomingTitlesFetcher.setState(SucessState(upcomingTitlesFetcher, titles))
        }

        override fun showFailure() {
            upcomingTitlesFetcher.setState(FailedState(upcomingTitlesFetcher))
        }

    }

    class SucessState(val upcomingTitlesFetcher: UpcomingTitlesFetcher, val list: List<String> = emptyList()) : State {
        override fun showInitial() {
            upcomingTitlesFetcher.setState(Initial(upcomingTitlesFetcher))
        }

        override fun showLoading() {
            throw IllegalStateException()
        }

        override fun showUpcomingTitles() {
            throw IllegalStateException()
        }

        override fun showFailure() {
            throw IllegalStateException()
        }

    }

    class FailedState(val upcomingTitlesFetcher: UpcomingTitlesFetcher ) : State {
        override fun showInitial() {
            upcomingTitlesFetcher.setState(Initial(upcomingTitlesFetcher))
        }

        override fun showLoading() {
            throw IllegalStateException()
        }

        override fun showUpcomingTitles() {
            throw IllegalStateException()
        }

        override fun showFailure() {
            throw IllegalStateException()
        }

    }
}

The code above defines a marker interface called State. State has four methods that defines the transition from one state to another. We also four state classes that implement the State interface. The state class themselves hold a reference to the context and define the state of the context.

For example, in the loading state below. When the showInitial is called an IllegalStateException is called because the programme is already in the loading state. It doesn't make any sense for the programme to switch to the initial state whilst in the loading state. It makes more sense to either transition to the success or failure state.

 class LoadingState(val upcomingTitlesFetcher: UpcomingTitlesFetcher) : State {
        init {
            upcomingTitlesFetcher.setState(this)
        }

        override fun showInitial() {
            throw IllegalStateException()
        }

        override fun showLoading() {
            upcomingTitlesFetcher.setState(LoadingState(upcomingTitlesFetcher))
        }

        override fun showUpcomingTitles() {
            val titles = getTitles()
            upcomingTitlesFetcher.setState(SucessState(upcomingTitlesFetcher, titles))
        }

        override fun showFailure() {
            upcomingTitlesFetcher.setState(FailedState(upcomingTitlesFetcher))
        }
    }

Now we include our states classes into the UpcomingTitlesFetcher.

class UpcomingTitlesFetcher {
    val intialState : State.Initial = State.Initial(this)
    val loadingState: State.LoadingState = State.LoadingState(this)
    val sucessResultState: State.SucessState = State.SucessState(this)
    val failureState: State.FailedState = State.FailedState(this)

    private var state: State = intialState

    fun getUpcomingTitles() {
        state.showInitial()
        println(state)
        state.showLoading()
        println(state)
        state.showUpcomingTitles()
        println(state)
    }

    private fun setState(state: State) {
        this.state = state
    }
}

I'll have to admit with this example, using the state pattern is a bit too much. There are two ways of changing states in the State pattern. Either the State classes change the state of the context or the Context itself changes its state.

Using the second approach, since the context is going to determine when to switch states. The State class can be refactored to this.

    sealed interface State2 {
        object Initial : State2
        object Loading : State2
        class Success(val data: List<String>) : State2
        class Failure(val error: String) : State2
    }

class UpcomingTitlesFetcher2 {
    private var state: State2 = State2.Initial

    fun getUpcomingTitles() {
        println(state)
        state = State2.Loading
        println(state)
        val titles = getTitles()
        state = State2.Success(titles)
        println(state)
    }

In my opinion, they both have their disadvantages and advantages. For simple states, like this one. I'd go with the second approach. For complicated states and events, I would prefer to encapsulate the state logic into different classes and have them change the state of the context.

Head First Design Pattern : 8 of 10

Oluwasanmi Aderibigbe — Sun, 29 Aug 2021 11:01:10 +0000

I just learnt a new design from the Head First Design Pattern book. Today, I learnt about the Iterator pattern.

According to the head-first design pattern, the Iterator pattern is a pattern that allows you to access the elements of a collection sequentially without exposing its underlying representation. It allows you to extract the transversal logic of collections. It does so in a way that it makes transversing elements of any collection easier.

Implementing the Iterator is pretty straightforward

Define an iterator interface

interface Iterator<out T> {
    fun hasNext() : Boolean
    fun next() : T
}

The Iterator interface below has two methods. The hasNext and the next. The hasNext is used to check if the collection has items remaining while the next is used to get the next item from the collection. Instead of creating your implementation of the Iterator interface, you can also use the Iterator interface in Java.

2.Create a class that implements the Iterator interface. As you can see they all contain different kinds of collections. Without the Iterator pattern, you'll have to transverse each collection separately.

class MangaIterator(val mangas: List<Manga>) : Iterator<Manga> {
    var position: Int = 0
        private set

    override fun hasNext(): Boolean {
        return if (position >= mangas.size || mangas.getOrNull(position) == null) false else true
    }

    override fun next(): Manga {
        val manga = mangas[position]
        position += 1
        return  manga
    }
}


class AnimeIterator(val animes: Array<Anime>) : Iterator<Anime>{
    var position: Int = 0
        private set

    override fun hasNext(): Boolean {
        return if (position >= animes.size || animes.getOrNull(position) == null) false else true
    }

    override fun next(): Anime {
        val manga = animes[position]
        position += 1
        return  manga
    }
}

class NovelIterator(val novels: HashMap<String, Novel>): Iterator<Novel> {
    var position: Int = 0
        private set

    override fun hasNext(): Boolean {
        return if (position >=    novels.values.size ||  novels.values.elementAt(position) == null) false else true

    }

    override fun next(): Novel {
        val novel = novels.values.elementAt(position)
        position += 1
        return  novel
    }
}

class TrackerApp() {
    fun <T> print(iterator: Iterator<T>) {
        while (iterator.hasNext()) {
            println(iterator.next())
        }
    }
}

fun main() {
    val manga = listOf<Manga>(
        Manga("Relife", "Slice of Life"),
        Manga("Koe no katachi", "Slice of Life"),
        Manga("Vagabond", "Action")
    )
    val anime = arrayOf(Anime("Konosuba", "Comedy"), Anime("Miss Koyobashi's Dragon maid", "Comedy"))
    val novels =
        hashMapOf<String, Novel>("Markus Zusak" to Novel("The book thief"), "Brandon Sanderson" to Novel("Mistborn"))

    val mangaIterator = MangaIterator(manga)
    val animeIterator = AnimeIterator(anime)
    val novelIterator = NovelIterator(novels)

    val trackerApp = TrackerApp()
    trackerApp.print(mangaIterator)
    trackerApp.print(animeIterator)
    trackerApp.print(novelIterator)

Manga(name=Relife, genre=Slice of Life)
Manga(name=Koe no katachi, genre=Slice of Life)
Manga(name=Vagabond, genre=Action)
Anime(name=Konosuba, genre=Comedy)
Anime(name=Miss Koyobashi's Dragon maid, genre=Comedy)
Novel(name=The book thief)
Novel(name=Mistborn)

}

Since the logic for transversing the collection has been encapsulated within an Iterator class. The TrackerApp can traverse any kind of collection so fat they implement the Iterator interface.
The Iterator pattern shines when you have transverse different kinds of collections.

Head First Design Pattern: 7 of 10

Oluwasanmi Aderibigbe — Sun, 25 Jul 2021 15:42:58 +0000

I just learnt a new design from the Head First Design Pattern book. Today, I learnt about the Template pattern.

According Head First Design Patterns, The template pattern is a pattern used to define the skeleton of an algorithm in a method(Template method), deferring some steps to subclasses. Template pattern lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.

For example you were asked to develop an app for making different kinds of burgers. Making burgers for the most part require the same steps. You could create a class for each burger you'd like to create or you could reuse code by implementing the template pattern.

Implementing the Template pattern is pretty straightforward.

1 First you have define the algorithm in an abstract class. Methods that must be implemented by the subclasses are marked as abstract.

abstract class Burger {
    abstract fun grillMeat()
    abstract fun addToppings()
    fun makePatties() {
        println("warming buns")
    }

    open fun deliver() {}

    fun prepareBurger() {
        makePatties()
        grillMeat()
        addToppings()
        deliver()
    }
}

2 Subclass the template class and provide the required behaviour

class ChickenBurger : Burger() {
    override fun grillMeat() {
        println("Grill chicken")
    }

    override fun addToppings() {
        println("Add things needed for chicken burger")
    }
}

class HamBurger : Burger() {
    override fun grillMeat() {
        println("Grill chicken")
    }

    override fun addToppings() {
        println("Add things needed for ham burger")
    }
}

With the Template pattern we reused code by moving almost everything required to make a burger into an abstract super class and then allow subclasses provide the missing steps.

The Template pattern can be improved by adding hooks. Hooks are essentially methods with default or empty implementation. They give the subclasses the ability to hook into the algorithm at various points. Hooks are somewhat of callbacks so to speak.

abstract class Burger {
    abstract fun grillMeat()
    abstract fun addToppings()
    fun makePatties() {
        println("warming buns")
    }

    open fun deliver() {}

    fun prepareBurger() {
        makePatties()
        grillMeat()
        addToppings()
        deliver()
    }
}

class ChickenBurger : Burger() {
    override fun grillMeat() {
        println("Grill chicken")
    }

    override fun addToppings() {
        println("Add things needed for chicken burger")
    }

    override fun deliver() {
        println("Deliver chicken burger")
    }
}

class HamBurger : Burger() {
    override fun grillMeat() {
        println("Grill chicken")
    }

    override fun addToppings() {
        println("Add things needed for ham burger")
    }
}

The code above implements a hook method called deliver. Burgers that are deliver-ably would simply override that method.

The template pattern is used a lot when it comes to creating frameworks, where the framework controls how things get done, but leaves you to specify some details.

The template pattern is prevalent in Android app development. An example of the template pattern is subclassing Fragments, Activities, anything that has to do with the Android SDK. Whenever you override any event method e.g onCreate(), you are essential hooking into the Android SDK.

Head First Design Pattern: 6 of 10

Oluwasanmi Aderibigbe — Mon, 19 Jul 2021 05:42:08 +0000

I just learnt a new design from the Head First Design Pattern book. Today, I learnt about the Adapter.

According to Head First Design Patterns, the Adapter pattern is a pattern that allows you to convert the interface of a class into another interface clients expects.
The adapter lets classes work together that couldn't otherwise because of incompatible interfaces. It does so by wrapping existing classes and mapping requests from the existing class to the new system.

Implementing the Adapter pattern is pretty straight. For example you were asked to work on a feature for your mobile app that requires you to integrate a third party library that only accepts data in XML.

interface XMLProvider {
    fun sendData(): List<XML>
}

class XML(val data: String)

class JSON(val data: String)

class JSONNetworkingClass() {
    fun sendData(): List<JSON> = listOf(JSON("jsonnnnnn derulo"))
}

class XMLToJsonAdapter(val jsonNetworkingClass: JSONNetworkingClass) : XMLProvider {

    override fun sendData(): List<XML> {
        //convert json to xml.
        return jsonNetworkingClass.sendData().map { XML(it.data) }
    }
}

fun main() {
val xmLLibrary = XMLLibrary.init(XMLToJsonAdapter())
}

When you need to use an existing class perhaps from legacy code or libraries and its interface is not one you need, use an adapter.
A common example of the adapter pattern would be the RecyclerView's adapter and Retrofit's adapters.

Head First Design Pattern: 5 of 10

Oluwasanmi Aderibigbe — Thu, 15 Jul 2021 19:20:59 +0000

I just learnt my fifth design from the Head First Design Pattern book. Today, I learnt about the Command pattern.

According to Head First Design Patterns, the Command pattern is a pattern that encapsulate a request as an object, thereby letting you parameterise other object with different requests, queue and also undo requests.

The command pattern works by decoupling by the object making the request(invoker) and the object that knows how to perform the request. It does this by encapsulating actions into command objects. The command object houses the receiver(which essentially the object performing the action) and it's actions.

The first step is implementing is defining a command interface. This interface defines an method called execute.
The second is creating command objects that implement the command interface.
The third is is creating the invoker class, SmartHomeApp. SmartHomeApp has no knowledge of the actions being performed anytime OnButtonTapped and offButtonTapped.

The code below is an example of the command pattern.

interface Command {
    fun execute(): Unit
}

class TurnOnLightsCommand : Command {
    override fun execute() {
        print("Light turned on")
    }
}

class TurnOffLightsCommand : Command {
    override fun execute() {
        print("Light turned off")
    }
}

class TurnOnTVCommand : Command {
    override fun execute() {
        print("TV turned on")
    }
}

class TurnOffTVCommand : Command {
    override fun execute() {
        print("TV turned off")
    }
}

interface Command {
    fun execute(): Unit
}

class TurnOnLightsCommand : Command {
    override fun execute() {
        println("Light turned on")
    }
}

class TurnOffLightsCommand : Command {
    override fun execute() {
        println("Light turned off")
    }
}

class TurnOnTVCommand : Command {
    override fun execute() {
        println("TV turned on")
    }
}

class TurnOffTVCommand : Command {
    override fun execute() {
        println("TV turned off")
    }
}


class SmartHomeApp {
    private val onCommands = mutableListOf<Command>()
    private val offCommands = mutableListOf<Command>()

    fun setCommand(slot: Int, onCommand: Command, offCommand: Command) {
        onCommands.add(slot, onCommand)
        offCommands.add(slot, offCommand)
    }

    fun onButtonTapped(slot: Int) {
        onCommands[slot].execute()
    }

    fun offButtonTapped(slot: Int) {
        offCommands[slot].execute()
    }
}

fun main() {
    val smartHomeApp = SmartHomeApp()

    smartHomeApp.setCommand(0, TurnOnLightsCommand(), TurnOffLightsCommand())
    smartHomeApp.setCommand(1, TurnOnTVCommand(), TurnOffTVCommand())

    smartHomeApp.onButtonTapped(0)
    smartHomeApp.onButtonTapped(1)

}

The command pattern can be used to implement really cool functionalities like undo, redo actions, performing a sequence of commands(Macros). It also allows you to queue and delay the execution of an action after request was made. With the command pattern you can also implement complex logging and state restoration logic.

Head First Design Pattern: 4 of 10

Oluwasanmi Aderibigbe — Sat, 03 Jul 2021 18:54:08 +0000

I just learnt my fourth design from the Head First Design Pattern book. Today, I learnt about the Singleton pattern.

According to Head First Design Patterns, the Singleton pattern is a pattern that is used to ensure a class has only one instance, and provides a global point of access to it.

For example, the singleton pattern can be implemented in Java like this

public class Singleton {
    private static Singleton instance;

    private Singleton() {
    }

    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

In order to ensure the Singleton class only has one instance, It's constructor is marked as private. Singleton has an API called getInstance().

The Singleton pattern seems like a very simple pattern but there are some gotchas you need to be aware of when it comes to using the Singleton pattern and multithreading. In a multithreaded code, it is possible to create multiple instances of the class above since multiple thread can have access to the getInstance function at the same time.
There are many ways to fix this:

1: Refactor the code above to use synchronised keyword.

public class Singleton {
    private volatile static Singleton instance;

    private Singleton() {
    }

    public static synchronised Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

By adding the synchronised keyboard to the getInstance() we are forcing every thread to wait it's turn before they enter the function. So only one thread can access the getInstance() function.

2: Simply use the Object keyword from Kotlin. Kotlin has the Singleton pattern built into the language with the Object keyword.

object Singleton {
}

If you need to have on instance of a class, for example, loggers, analytics, crash reporting. You should use the Singleton pattern

Head First Design Pattern: 3 or 10

Oluwasanmi Aderibigbe — Fri, 02 Jul 2021 20:16:01 +0000

I just learnt my third design from the Head First Design Pattern book. Today, I learnt about the Abstract Factory method and Factory Method.

According to Head First Design Patterns, the Factory Method pattern is a pattern that allows you to defer the instantiation of an object to a subclass. It does so by defining an interface and letting its subclasses design which class to instantiate.
The Abstract Factory is a design pattern that provides an interface for creating a family of related objects without specifying their concrete classes.

These two design patterns help you decouple your code from concrete classes. Thereby promoting loose coupling between your classes. The Factory method relies on inheritance to achieve this loose coupling. It delegates the logic of creating concrete classes to its subclasses while the Abstract Factory pattern relies on object composition.

Whenever you have a family of related objects to create, you should use the Abstract Factory Pattern else use the Factory Method pattern.

Head First Design Patterns: 2 of 10

Oluwasanmi Aderibigbe — Thu, 24 Jun 2021 05:20:44 +0000

I just learnt my second design from the Head First Design Pattern book. Today, I learnt about the Decorator pattern.

According to Head First Design Patterns, the Decorator pattern is a pattern used to attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

This simply means Decorators allow you to add new behaviours to a class by wrapping them in a wrapper class. A wrapper is an object that has a reference to a target class and delegates all actions to the target class.
Decorators must be of the same type of the wrapped class. This is what makes the decorator pattern different from a normal wrapper.

Decorators come in handy situations such as these:

Adding new behaviour to classes you don't own.
A situation whereby using inheritance would lead to too many classes because of the different scenarios that must be covered by the software. For example, you were asked to design a software that calculates the total price of food for a Nigerian native restaurant. Because of the various combinations of solids and soups, there would be a lot of classes to create and maintain.

In situations such as these, you can use the Decorator pattern. Here's how to implement the Decorator pattern.

abstract class Solid {
    abstract val description: String
    abstract val price: Int
}

class Eba : Solid() {
    override val description: String
        get() = "Eba"
    override val price: Int
        get() = 100
}

class Fufu : Solid(){
    override val description: String
        get() = "Fufu"
    override val price: Int
        get() = 200

}

abstract class SolidDecorator(val solid: Solid) : Solid() {
    abstract override val description: String
}

class NativeSoupDecorator(solid: Solid) : SolidDecorator(solid) {
    override val description: String
        get() = "${solid.description} with Native Soup"
    override val price: Int
        get() = solid.price + 500
}

class AfangSoupDecorator(solid: Solid) : SolidDecorator(solid) {
    override val description: String
        get() = "${solid.description} with Afang Soup"
    override val price: Int
        get() = solid.price + 500
}

Like I said before, Decorators are a special kind of wrappers. Take a look at the SolidDecorator abstract class. It has a reference to a Solid class and it also subclasses Solid. This is what makes Decorators special. You can then create many concrete classes of the SolidDecorator adding new behaviours to the initial wrapped class. Decorators can also add their behaviour before and/or after delegating actions to the target object.

    var order : Solid = Eba()
    order = NativeSoupDecorator(solid = order)
    order = AfangSoupDecorator(solid = order)
    order = FishDecorator(order)
    println("${order.description} price: ${order.price}")

    var order2 : Solid = Eba()
    order2 = NativeSoupDecorator(solid = order2)
    order2 = GoatMeatDecorator(solid = order2)
    println("${order2.description} price: ${order2.price}")

Eba, Native Soup, Afang Soup, goat meat price: 2100
Eba, Native Soup, goat meat price: 650

An example of the decorator pattern in android development can be found in this library: https://github.com/nhaarman/ListViewAnimations

Day 100 of 100 Days of SwiftUI

Oluwasanmi Aderibigbe — Tue, 22 Jun 2021 06:37:13 +0000

I just completed day 100 of 100 days of swiftui. I took the final exam and i passed!!!!

Day 99 of 100 Days of SwiftUI

Oluwasanmi Aderibigbe — Mon, 21 Jun 2021 17:39:59 +0000

I just completed day 99 of 100 days of SwiftUI. Today, I worked on the app challenge for Snowseeker app.
I persisted user favourited resorts and also added photo credits to the Resort list screen.