TL;DR: The Prototype design pattern creates new objects by cloning a prototypical instance, allowing you to modify the copy without creating an object from scratch. This pattern is useful when object creation is expensive or when classes to instantiate are specified at runtime.

Intent

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

Explanation

First, it should be noted that the Prototype pattern is not used to gain performance benefits. It's only used for creating new objects from prototype instances.

Real-world example

Remember Dolly? The sheep that was cloned! Let's not get into the details but the key point here is that it is all about cloning.

In plain words

Create an object based on an existing object through cloning.

Wikipedia says

The prototype pattern is a creational design pattern in software development. It is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects.

In short, it allows you to create a copy of an existing object and modify it to your needs, instead of going through the trouble of creating an object from scratch and setting it up.

Programmatic Example

In Kotlin, the prototype pattern is recommended to be implemented as follows. First, create an interface with a method for cloning objects. In this example, Prototype interface accomplishes this with its clone method. We will then use the copy() function of data class to create a clone of our class where we can override specific fields of the class if needed.

abstract class Prototype<T> {
  abstract fun clone(): T
}

Our example contains a hierarchy of different creatures. For example, let's look at Beast and OrcBeast classes.

abstract class Beast : Prototype<Beast>()

data class OrcBeast(private val weapon: String) : Beast() {

  override fun clone() = copy()

  override fun toString() = "Orcish wolf attacks with $weapon"
}

We don't want to go into too many details, but the full example contains also base classes Mage and Warlord and there are specialized implementations for those for elves in addition to orcs.

To take full advantage of the prototype pattern, we create HeroFactory class to produce different kinds of creatures from prototypes.

class HeroFactory(
  private val mage: Mage,
  private val warlord: Warlord,
  private val beast: Beast,
) {
  fun createMage() = mage.clone()

  fun createWarlord() = warlord.clone()

  fun createBeast() = beast.clone()
}

Now, we are able to show the full prototype pattern in action producing new creatures by cloning existing instances.

var factory = HeroFactory(
  ElfMage("cooking"),
  ElfWarlord("cleaning"),
  ElfBeast("protecting")
)

var mage = factory.createMage()
var warlord = factory.createWarlord()
var beast = factory.createBeast()

logger.info(mage.toString())
logger.info(warlord.toString())
logger.info(beast.toString())

factory = HeroFactory(
  OrcMage("axe"),
  OrcWarlord("sword"),
  OrcBeast("laser")
)

mage = factory.createMage()
warlord = factory.createWarlord()
beast = factory.createBeast()

logger.info(mage.toString())
logger.info(warlord.toString())
logger.info(beast.toString())

Here's the console output from running the example.

Elven mage helps in cooking
Elven warlord helps in cleaning
Elven eagle helps in protecting
Orcish mage attacks with axe
Orcish warlord attacks with sword
Orcish wolf attacks with laser

Class diagram

Applicability

Use the Prototype pattern when a system should be independent of how its products are created, composed, represented and

• When the classes to instantiate are specified at run-time, for example, by dynamic loading.

• To avoid building a class hierarchy of factories that parallels the class hierarchy of products.

• When instances of a class can have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state.

• When object creation is expensive compared to cloning.

Code Examples

All code examples and tests can be found in the Kotlin Design Patterns repository

Credits

• Java Design Patterns

• Design Patterns: Elements of Reusable Object-Oriented Software

• Head First Design Patterns: A Brain-Friendly Guide

TL;DR: Separate the construction of a complex object from its representation so that the same construction process can create different representations.

Intent

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

Explanation

Real-world example

Imagine a character generator for a role-playing game. The easiest option is to let the computer create the character for you. If you want to manually select the character details like profession, gender, hair color, etc. the character generation becomes a step-by-step process that completes when all the selections are ready.

In plain words

Allows you to create different flavors of an object while avoiding constructor pollution. Useful when there are several flavours of an object. Or when there are a lot of steps involved in the creation of an object.

Wikipedia says

The builder pattern is an object creation software design pattern with the intentions of finding a solution to the telescoping constructor anti-pattern.

Having said that let me add a bit about what telescoping constructor anti-pattern is. At one point or the other, we have all seen a constructor like below:

data class Hero(
  val profession: Profession,
  val name: String,
  val hairType: HairType?,
  val hairColor: HairColor?,
  val armor: Armor?,
  val weapon: Weapon?
)

As you can see the number of constructor parameters can quickly get out of hand, and it may become difficult to understand the arrangement of parameters. Plus this parameter list could keep on growing if you would want to add more options in the future. This is called a telescoping constructor anti-pattern.

Programmatic Example

The sane alternative is to use the Builder pattern. First of all, we have our hero that we want to create:

data class Hero(
  val profession: Profession,
  val name: String,
  val hairType: HairType?,
  val hairColor: HairColor?,
  val armor: Armor?,
  val weapon: Weapon?
) {
  private constructor(builder: Builder) : this(
    builder.profession,
    builder.name,
    builder.hairType,
    builder.hairColor,
    builder.armor,
    builder.weapon
  )
}

Then we have the builder:

class Builder(profession: Profession?, name: String?) {
  val profession: Profession
  val name: String
  var hairType: HairType? = null
  var hairColor: HairColor? = null
  var armor: Armor? = null
  var weapon: Weapon? = null

  init {
    require(!(profession == null || name == null)) { "profession and name can not be null" }
    this.profession = profession
    this.name = name
  }

  fun withHairType(hairType: HairType?): Builder = apply {
    this.hairType = hairType
  }

  fun withHairColor(hairColor: HairColor?): Builder = apply {
    this.hairColor = hairColor
  }

  fun withArmor(armor: Armor?): Builder = apply {
    this.armor = armor
  }

  fun withWeapon(weapon: Weapon?): Builder = apply {
    this.weapon = weapon
  }

  fun build() = Hero(this)
}

Then it can be used as:

val mage = Hero.Builder(Profession.MAGE, "Riobard")
  .withHairColor(HairColor.BLACK)
  .withWeapon(Weapon.DAGGER)
  .build()

However, Kotlin provides an alternative to the Builder pattern with named arguments and default parameter values:

data class Hero(
    val profession: Profession,
    val name: String,
    val hairType: HairType? = null,
    val hairColor: HairColor? = null,
    val armor: Armor? = null,
    val weapon: Weapon? = null
)

Then it can be used as:

val mage = Hero(
    profession = Profession.MAGE,
    name = "Riobard",
    hairColor = HairColor.BLACK,
    weapon = Weapon.DAGGER
)

Not only that the code simpler, but we are also enforcing the required parameters at compile time.

Class diagram

Applicability

Use the Builder pattern when

• The algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled

• The construction process must allow different representations for the object that's constructed

Tutorials

• Refactoring Guru

• Oracle Blog

• Journal Dev

Code Examples

All code examples and tests can be found in the Kotlin Design Patterns repository

Credits

• Java Design Patterns

• Design Patterns: Elements of Reusable Object-Oriented Software

• Effective Java

• Head First Design Patterns: A Brain-Friendly Guide

• Refactoring to Patterns

• Kotlin Design Patterns and Best Practices

TL;DR: Abstract Factory pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. This pattern is useful when the system needs to be independent of how its products are created, composed, and represented, and when there are multiple families of products that need to be used together.

Also known as

• Kit

Intent

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Explanation

Real-world example

To create a kingdom we need objects with a common theme. The elven kingdom needs an elven king, elven castle, and elven army whereas the orcish kingdom needs an orcish king, orcish castle, and orcish army. There is a dependency between the objects in the kingdom.

In plain words

A factory of factories; is a factory that groups the individual but related/dependent factories together without specifying their concrete classes.

Wikipedia says

The abstract factory pattern provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes

Programmatic Example

Translating the kingdom example above. First of all, we have some interfaces and implementations for the objects in the kingdom.

internal interface Castle {
  val description: String
}

internal interface King {
  val description: String
}

internal interface Army {
  val description: String
}

// Elven implementations ->

internal class ElfCastle : Castle {
  override val description = "This is the elven castle!"
}

internal class ElfKing : King {
  override val description = "This is the elven king!"
}

internal class ElfArmy : Army {
  override val description = "This is the elven army!"
}

// Orcish implementations similarly -> ...

Then we have the abstraction and implementations for the kingdom factory.

internal interface KingdomFactory {
  fun createCastle(): Castle
  fun createKing(): King
  fun createArmy(): Army
}

internal class ElfKingdomFactory : KingdomFactory {
  override fun createCastle() = ElfCastle()
  override fun createKing() = ElfKing()
  override fun createArmy() = ElfArmy()
}

internal class OrcKingdomFactory : KingdomFactory {
  override fun createCastle() = OrcCastle()
  override fun createKing() = OrcKing()
  override fun createArmy() = OrcArmy()
}

Now we have the abstract factory that lets us make a family of related objects i.e. elven kingdom factory creates an elven castle, king and army, etc.

val factory = ElfKingdomFactory()
val castle = factory.createCastle()
val king = factory.createKing()
val army = factory.createArmy()

castle.description
king.description
army.description

Program output:

This is the elven castle!
This is the elven king!
This is the elven Army!

Now, we can design a factory for our different kingdom factories. In this example, we created FactoryMaker, responsible for returning an instance of either ElfKingdomFactory or OrcKingdomFactory.
The client can use FactoryMaker to create the desired concrete factory which, in turn, will produce different concrete objects (derived from Army, King, Castle).
In this example, we also used an enum to parameterize which type of kingdom factory the client will ask for.

internal data class Kingdom(
  val king: King,
  val castle: Castle,
  val army: Army,
) {
  object FactoryMaker {
    enum class KingdomType {
      ELF,
      ORC
    }

    fun makeFactory(type: KingdomType): KingdomFactory {
      return when (type) {
        KingdomType.ELF -> ElfKingdomFactory()
        KingdomType.ORC -> OrcKingdomFactory()
      }
    }
  }
}

Now we can use the abstract factory to create the kingdoms

logger.info("elf kingdom")
val elfKingdom = createKingdom(KingdomType.ELF)
logger.info(elfKingdom.army.description)
logger.info(elfKingdom.castle.description)
logger.info(elfKingdom.king.description)

logger.info("orc kingdom")
val orcKingdom = createKingdom(KingdomType.ORC)
logger.info(orcKingdom.army.description)
logger.info(orcKingdom.castle.description)
logger.info(orcKingdom.king.description)

Program output:

elf kingdom
This is the elven castle!
This is the elven king!
This is the elven Army!
orc kingdom
This is the orc castle!
This is the orc king!
This is the orc Army!

Class diagram

Applicability

Use the Abstract Factory pattern when

• The system should be independent of how its products are created, composed, and represented

• The system should be configured with one of the multiple families of products

• The family of related product objects is designed to be used together, and you need to enforce this constraint

• You want to provide a class library of products, and you want to reveal just their interfaces, not their implementations

• The lifetime of the dependency is conceptually shorter than the lifetime of the consumer.

• You need a run-time value to construct a particular dependency

• You want to decide which product to call from a family at runtime.

• You need to supply one or more parameters only known at run-time before you can resolve a dependency.

• When you need consistency among products

• You don’t want to change existing code when adding new products or families of products to the program.

Example use cases

• Selecting to call to the appropriate implementation of FileSystemAcmeService or DatabaseAcmeService or NetworkAcmeService at runtime.

• Unit test case writing becomes much easier

• UI tools for different OS

Consequences

• Dependency injection in Java hides the service class dependencies that can lead to runtime errors that would have been caught at compile time.

• While the pattern is great when creating predefined objects, adding new ones might be challenging.

• The code becomes more complicated than it should be since many new interfaces and classes are introduced along with the pattern.

Tutorials

• Abstract Factory Pattern Tutorial

Code Examples

All code examples and tests can be found in the Kotlin Design Patterns repository

Related patterns

• Factory Method

• Factory Kit

Credits

• Java Design Patterns

• Design Patterns: Elements of Reusable Object-Oriented Software

• Head First Design Patterns: A Brain-Friendly Guide

TL;DR: Factory pattern provides a static method encapsulated in a class to hide implementation logic, allowing client code to focus on usage rather than object initialization. It simplifies object creation, promotes loose coupling, and supports easy switching between object types without modifying existing code.

Also known as

• Factory

• Simple Factory

Intent

Providing a static method encapsulated in a class called the factory, to hide the implementation logic and make client code focus on usage rather than initializing new objects.

Explanation

Real-world example

Imagine an alchemist who is about to manufacture coins. The alchemist must be able to create both gold and copper coins and switching between them must be possible without modifying the existing source code. The factory pattern makes it possible by providing a static construction method which can be called with relevant parameters.

Wikipedia says

A factory is an object for creating other objects – formally a factory is a function or method that returns objects of a varying prototype or class.

Programmatic Example

We have an interface Coin and two implementations GoldCoin and CopperCoin.

internal interface Coin {
    val description: String
}

internal class GoldCoin : Coin {
    override val description = "This is a gold coin."
}

internal class CopperCoin : Coin {
    override val description = "This is a copper coin."
}

The enumeration above represents the types of coins that we support (GoldCoin and CopperCoin).

internal enum class CoinType(val constructor: () -> Coin) {
    COPPER({ CopperCoin() }),
    GOLD({ GoldCoin() }),
}

Then we have the static method getCoin to create coin objects encapsulated in the factory class CoinFactory.

internal object CoinFactory {
    fun getCoin(type: CoinType): Coin = type.constructor()
}

Now on the client code, we can create different types of coins using the factory class.

logger.info("The alchemist begins his work.")
val copper = CoinFactory.getCoin(CoinType.COPPER)
val gold = CoinFactory.getCoin(CoinType.GOLD)
logger.info(copper.description)
logger.info(gold.description)

Program output:

The alchemist begins his work.
This is a copper coin.
This is a gold coin.

Class Diagram

Applicability

Use the factory pattern when you only care about the creation of an object, not how to create and manage it.

Pros

• Allows keeping all objects created in one place.

• Allows to write loosely coupled code. Some of its main advantages include better testability, easy-to-understand code, swappable components, scalability, and isolated features.

Cons

• The code becomes more complicated than it should be.

Code Examples

All code examples and tests can be found in the Kotlin Design Patterns repository

Related patterns

• Factory Method

• Abstract Factory

• Factory Kit

Credits

• Java Design Patterns

TL;DR: This article shares my experience with a temporary solution that turned into a long-term issue. I discuss the evolution of a service and how it improved its performance by over 450% in a few hours. The story highlights the importance of addressing temporary solutions and constantly evaluating system design to optimize performance.

Introduction

About four years ago, around the time I joined my previous employer, my manager at the time introduced me to one of the services my team owned. He opened the explanation with the sentence, "As the saying goes, nothing is more permanent than a temporary solution". More than five years have passed since this service was initially introduced, and it's still running in production.

In this article, I share a specific use case of the service and how we improved its performance by over 450% in just a few hours.

The Original System Design

Let's start by briefly looking at the system's original design. The system included a database that serves as the source of the data, a poller service that checks for changes in the source database every five seconds, and in case a change is found, it aggregates the data and stores it in a different database. Lastly, a Reader service is responsible for reading the aggregated data from the database and serving it to our clients.

As you might already imagine, integration via a database is almost always a bad idea. It can lead to data inconsistency, lack of real-time updates, difficulty in making changes in the database schema, and more. But as we just said, temporary solution - right? Our system specifically suffered mainly from data inconsistency. The main root cause for the issues was been that the entities in the database might not yet be finalized by the time they were polled. In such a case, the poller would ignore the data and would never return to fix it later.

Addressing Data Inconsistency

Eventually, the data-owning team began publishing events indicating that the data was finalized and ready for use. We amended our poller service, so it would start to listen to those events and store the IDs of the entities that are ready to be picked in a table that it would later poll. This ensures no data is missed. With the new change, our system now looks as follows:

You might ask: "Why didn't you change the implementation to rely completely on the events?". Well... First, the events lacked the required information. The only reason the data exists in the database, to begin with, is because of domain mixing. The mix in domains has been so deep that multiple teams worked very hard for a very long time to split those domains.

The Human Error

At this point, it's worth stopping and discussing the human aspect behind the existence of this solution. The poller service was introduced as a technical solution for a technical problem. We needed access to data that we didn't have, and with the help of this service, we had that access (even if it caused a violation of multiple domain boundaries).

However, as we made the poller stable it fell lower and lower in the priority list of the company to replace this design with a proper solution. Not only that, but the maintenance of the service moved between teams in the company like a hot potato. In my time in the company, I actually had the pleasure of working on this system in 3 different contexts and teams.

The lack of real ownership of the system, higher company priorities, and management's general agreement that the solution wasn't great but worked, led to the repeated de-prioritization of refactoring this part of the system.

Introducing New Features and Challenges

The system functioned and was left unchanged for some time. Until one day, we had to introduce another new feature. The feature required to generate information for our clients about the previous day. The data should be available every day at 5 a.m. (client's local time).

To solve this problem, we first introduced a new service responsible for managing day opening/closing. Next, the poller service made a REST call to the new service for each entity in the database and assigned the ID of the current day. Lastly, the Read service aggregated the data from the database and used it to generate the required information.

Our system now looked like this:

As you can imagine, using REST calls between the poller and the new service created a strong coupling. Every time we had to maintain the database of the day management service, our poller service received an internal error response from the REST call and did not assign an ID to the entity. We could resolve this situation by using asynchronous communication between the services. In such a case, the Day management service would notify all consumers whenever a new day is opened/closed and let them do as they wish with the information. Such a solution would allow scalability of the system, resiliency, and avoid coupling between the services (or as my favorite phrase says, building a distributed monolith).

Yet another issue, when the clients activated the feature, we did not assign the ID of the day to already existing entities. The impact of that was that the data from the first day was incomplete at best, or completely wrong at worst. This caused many calls to our support agents and wasted quite a significant amount of the team's time debugging the issue.

Performance Issues and Materialized Views

We rolled out the feature to 1000 clients. After about two weeks, we discovered that we had severe performance issues with our new feature. The issue was related to the SQL query we used to build the required information, which included multiple JOINs.

Since the data doesn't have to be updated during the day but only in the morning, we decided to come up with a new approach. We introduced a materialized view that was holding all the required information for the feature pre-calculated and refreshed the view every morning.

If you're unfamiliar with the materialized view in SQL, it is a database object that contains the results of a query, stored in a table-like structure. It is used to cache the results of complex queries for faster access and improved performance. Materialized views are periodically updated by refreshing the stored data, either manually or automatically, to keep the view in sync with the underlying data.

That means that from that point on, our poller started to refresh the materialized view every day. That was supposed to be a temporary solution until we find a more suitable database for our needs (where did I hear this before?)

At this point, I would like to stop and point out a few flaws in the above design with the requirements we had:

• Since we rolled out in multiple time zones, and we had only one view, we could not serve the information for our client at 5 a.m. anymore; the refresh had to happen when the client with the latest timezone hit this time.

• Materialized view does not support partial refresh, which means that every day we had to refresh all the data that was included in the feature, for all of our clients.

The solution kind of worked for a while. However, as the number of clients using the feature grew, and the amount of data we collected for each of them also grew, the refresh of the materialized view started to become heavy. It became so heavy that at some point it took almost 5 hours to refresh the view.

Not only did our API not match its target, but it also consumed a lot of resources from our database, which caused a lot of headaches for our database admins.

The Efficient Solution and its Benefits

Some time passed by, and a colleague of mine reached out to me and told me, "I think that I know how to fix the issue!". Instead of refreshing all the data every day, let's create a new table that would hold the pre-calculated data, we will run a job that would be executed periodically, and calculate only the delta since the previous calculation. The idea was genius by its simplicity!

We decided to make a POC for the above suggestion and check if it can be implemented. In six hours, we deployed a working POC in our staging environment, tested it, and with an additional day of work we went all the way to production.

After some testing, we set our refresh period to 1 minute and noticed that the query takes now around 1.4 seconds to be executed. With that, our saga came to an end.

As you can see in the graph below, our CPU usage for the database dropped dramatically after the changes!

With those changes, we regained:

• Minimal resource consumption by the database.

• Near-real-time information availability for clients instead of a 5-hour delay

• Simpler, easier-to-understand codebase.

To Be Continue?

While the story of the poller does not end here, my story in the company does. After almost 4.5 years I contacted my first manager in the company and told him that I had failed to sunset the poller. However, there is good news on the horizon. A new dedicated team starting to work now on re-writing the entire system from the ground, basing it on the right data sources, and hopefully soon enough the poller story will come to an end! 🤞

Conclusion

This cautionary tale demonstrates the importance of addressing temporary solutions and constantly evaluating system design to optimize performance. By implementing a more efficient approach to handling growing data and client needs, the team significantly improved their system's performance, resource consumption, and overall simplicity.

Remember, temporary solutions are never temporary!

Every tech debt decision you make will come back and hunt you if you are not going to come back and fix it later.

TL;DR: Factory Method is a design pattern that defines an interface for creating objects, allowing subclasses to decide which class to instantiate, thus delegating instantiation logic to child classes.

Also known as

• Virtual Constructor

Intent

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Explanation

Real-world example

Blacksmith manufactures weapons. Elves require Elvish weapons and orcs require Orcish weapons. Depending on the customer at hand the right type of blacksmith is summoned.

In plain words

It provides a way to delegate the instantiation logic to child classes.

Wikipedia says

In class-based programming, the factory method pattern is a creational pattern that uses factory methods to deal with the problem of creating objects without having to specify the exact class of the object that will be created. This is done by creating objects by calling a factory method — either specified in an interface and implemented by child classes, or implemented in a base class and optionally overridden by derived classes—rather than by calling a constructor.

Programmatic Example

Take our blacksmith example above. First of all, we have a Blacksmith interface and some implementations for it:

internal interface Blacksmith {
  fun manufactureWeapon(weaponType: WeaponType): Weapon
}

internal class ElfBlacksmith : Blacksmith {
  override fun manufactureWeapon(weaponType: WeaponType): Weapon =
    ELF_ARSENAL.getOrElse(weaponType) {
      throw IllegalArgumentException("Weapon type $weaponType is not supported by elf blacksmith.")
    }
}

internal class OrcBlacksmith : Blacksmith {
  override fun manufactureWeapon(weaponType: WeaponType): Weapon =
    ORC_ARSENAL.getOrElse(weaponType) {
      throw IllegalArgumentException("Weapon type $weaponType is not supported by the orc blacksmith.")
    }
}

When the customers come, the correct type of blacksmith is summoned and the requested weapons are manufactured:

// Orc
var blacksmith: Blacksmith = OrcBlacksmith()

var weapon: Weapon = blacksmith.manufactureWeapon(WeaponType.SPEAR)
logger.info("$blacksmith manufactured ${weapon.weaponType.title}")

weapon = blacksmith.manufactureWeapon(WeaponType.AXE)
logger.info("$blacksmith manufactured ${weapon.weaponType.title}")

// Elf
blacksmith = ElfBlacksmith()

weapon = blacksmith.manufactureWeapon(WeaponType.SPEAR)
logger.info("$blacksmith manufactured ${weapon.weaponType.title}")

weapon = blacksmith.manufactureWeapon(WeaponType.AXE)
logger.info("$blacksmith manufactured ${weapon.weaponType.title}")

Program output:

The orc blacksmith manufactured spear
The orc blacksmith manufactured axe
The elf blacksmith manufactured spear
The elf blacksmith manufactured axe

Class diagram

Applicability

Use the Factory Method pattern when:

• The class cannot anticipate the class of objects it must create.

• The class wants its subclasses to specify the objects it creates.

• Classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.

Code Examples

All code examples and tests can be found in the Kotlin Design Patterns repository

Credits

• Java Design Patterns

• Design Patterns: Elements of Reusable Object-Oriented Software

• Head First Design Patterns: A Brain-Friendly Guide

• Refactoring to Patterns

TL;DR: Ensure a class has only one instance and provide a global access point to it with the Singleton pattern, which is useful for coordinating actions across a system.

Intent

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

Explanation

Real-world example

There can only be one ivory tower where the wizards study their magic. The same enchanted ivory tower is always used by the wizards. The ivory tower here is a singleton.

In plain words

Ensures that only one object of a particular class is ever created.

Wikipedia says

In software engineering, the singleton pattern is a software design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system.

Programmatic Example

Kotlin makes it externally easy to create singletons by introducing the language keyword object. By using this keyword, we will get an implementation of the Singleton pattern from the compiler that contains all of our requirements.

data object IvoryTower

One of the key differences between a class and a object is that the latter does not allow constructor arguments. If your implementation needs initialization for your Singleton (e.g. to load data) you can use an init block.

data object IvoryTower {
  init {
    logger.info("Initializing Ivory Tower...")
  }
}

Note that if the Singleton object is never invoked, it won't run its initialization block at all. This is called lazy initialization.

Then in order to use:

val ivoryTower1 = IvoryTower
val ivoryTower2 = IvoryTower
logger.info("ivoryTower1={}", ivoryTower1)
logger.info("ivoryTower2={}", ivoryTower2)

The output on the console:

09:21:31.107 [main] INFO Singlton -- Initializing Ivory Tower...
09:21:31.109 [main] INFO Singlton -- ivoryTower1=com.yonatankarp.singleton.IvoryTower@1207938418
09:21:31.111 [main] INFO Singlton -- ivoryTower2=com.yonatankarp.singleton.IvoryTower@1207938418

Class diagram

Applicability

Use the Singleton pattern when

• There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point

• When the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code

Some typical use cases for the Singleton

• The logging class

• Managing a connection to a database

• File manager

Consequences

• Violates the Single Responsibility Principle (SRP) by controlling their creation and lifecycle.

• Encourages using a globally shared instance which prevents an object and resources used by this object from being deallocated.

• Creates tightly coupled code. The clients of the Singleton become difficult to test.

• It makes it almost impossible to subclass a Singleton.

Code Examples

All code examples and tests can be found in the Kotlin Design Patterns repository

Credits

• Java Design Patterns

• Kotlin Design Patterns and Best Practices

TL;DR: Respect object boundaries: avoid coupling to data and prioritize interfaces and behavior.

• When you view your objects merely as data holders, you risk violating their encapsulation.

Problem

• Information Hiding Violation

• Encapsulation Violation

• Coupling

Solution

• Always couple to interfaces and behavior, not data.

Sample Code

Wrong

data class Point(var x: Double, var y: Double)

class DistanceCalculator {
    fun distanceBetween(origin: Point, destination: Point): Double {
        return sqrt(
            (destination.x - origin.x).pow(2) +
                    (destination.y - origin.y).pow(2)
        )
    }
}

Right

data class Point(
    private val radius: Double,
    private val theta: Double
) {
    val x: Double get() = radius * cos(theta)
    val y: Double get() =  radius * sin(theta)
}

class DistanceCalculator {
    fun distanceBetween(origin: Point, destination: Point): Double {
        return sqrt(
            (destination.x - origin.x).pow(2) +
                    (destination.y - origin.y).pow(2)
        )
    }
}

Conclusion

If your classes are polluted with setters, getters and public methods you will certainly have ways to couple to their accidental implementation.

Credits

• Code Smell 55 - Object Orgy by Maximiliano Contieri

TL;DR: Avoid index-based iteration. Embrace higher-order collection functions.

Problem

• Violation of encapsulation

• Lack of declarativeness

Solution

• Opt for forEach() or high-order iterators.

• Concealing implementation details opens up possibilities like caching, proxies, lazy loading, and more.

Sample Code

Wrong

for(i in 0 until colors.count()) {
    print(colors[i])
}

// For Kotlin 1.9 and above, the 'until' can (and should) be
// substituted with '..<' to denote a range from 0 to 
// colors.count(), excluding the end.

Right

for(color in colors) {
    println(color)
}

// Utilizing closures and arrow functions
colors.forEach { println(it) }

Exceptions

Should the problem domain necessitate elements being mapped to natural numbers like indices, then the initial method may suffice.

Always strive to draw parallels with real-world scenarios.

Conclusion

Many developers overlook this kind of code smell, dismissing it as a minor detail.

Yet, it's the accumulation of such declarative nuances that truly elevates code quality.

Credits

• Code Smell 53 - Explicit Iteration by Maximiliano Contieri

TL;DR: Steer clear of non-deterministic tests..

Problem

• Lack of determinism

• Eroding confidence

• Time squandered

Solution

1. Ensure that the test is fully deterministic. Eradicate any potential for unpredictable behavior.

2. Eliminate test coupling.

Examples

The terms "Fragile," "Intermittent," "Sporadic," and "Erratic" are often used interchangeably when discussing problematic tests in many development environments.

However, such tests erode the trust developers place in their test suites.

Such tests are best avoided.

Sample Code

Wrong

import org.junit.jupiter.api.Assertions.assertEquals
import org.junit.jupiter.api.Test

abstract class SetTest {

    protected abstract fun constructor(): MutableSet<String>

    @Test
    fun `test add empty`() {
        val set = constructor()
        set.add("green")
        set.add("blue")
        assertEquals("[green, blue]", set.toString())
        // This is fragile since the outcome hinges on the set's
        // ordering, which isn't predefined and can vary based on
        // the set's implementation.
    }
}

Right

import org.junit.jupiter.api.Test
import kotlin.test.assertEquals
import kotlin.test.assertTrue

abstract class SetTest {

    protected abstract fun constructor(): MutableSet<String>

    @Test
    fun `test add empty`() {
        val set = constructor()
        set.add("green")
        assertEquals("[green]", set.toString())
    }

    @Test
    fun `test entry at single entry`() {
        val set = createFromArgs("red")
        val result = set.contains("red")
        assertTrue(result)
    }
}

Conclusion

Fragile tests often indicate system coupling and manifest as non-deterministic or unpredictable behaviors.

Addressing and resolving these erratic tests can drain considerable developer time and energy.

Credits

• Code Smell 51 - Fragile Tests by Maximiliano Contieri

TL;DR - Caches discusses the problems with caching, such as coupling and maintainability, and proposes solutions like using an object mediator, testing invalidation scenarios, and modeling real-world cache metaphors. It concludes that caches should be functional, and intelligent, and domain objects shouldn't be cached.

Problem

• Coupling

• Testability

• Cache Invalidation

• Maintainability

• Premature Optimization

• Erratic Behavior

• Lack of Transparency

• Non-Deterministic Behavior

Solution

1. If you have a conclusive benchmark and are willing to accept some coupling, put an object in the middle.

2. Unit test all your invalidation scenarios. Experience shows that we face them in an incremental way.

3. Look for a real-world cache metaphor and model it.

Sample Code

Wrong

typealias Cache<T> = MutableMap<String, List<T>>

class Book(
    private val cachedBooks: Cache<Book> = mutableMapOf()
) {
    fun getBooks(title: String): List<Book> {
        return if (cachedBooks.containsKey(title)) {
            cachedBooks[title]!!
        } else {
            val booksFromDatabase = getBooksFromDatabase(title)
            cachedBooks[title] = booksFromDatabase
            booksFromDatabase
        }
    }

    private fun getBooksFromDatabase(title: String): List<Book> =
        globalDatabase().selectFrom("Books", "WHERE TITLE = $title")
}

Right

typealias Cache<T> = MutableMap<String, T>

interface BookRetriever {
    fun bookByTitle(title: String): Book?
}

class Book {
    // Just Book-related Stuff
}

class DatabaseLibrarian : BookRetriever {
    // Go to the database (not global hopefully)
    override fun bookByTitle(title: String): Book? { ... }
}

// We always look for real-life metaphors
class HotSpotLibrarian(
    private val inbox: Inbox,
    private val realRetriever: BookRetriever
) : BookRetriever {
    override fun bookByTitle(title: String): Book? {
        return if (inbox.includesTitle(title)) {
            // We are lucky. Someone has just returned the book copy.
            inbox.retrieveAndRemove(title)
        } else {
            realRetriever.bookByTitle(title)
        }
    }
}

class Inbox(private val books: Cache<Book> = mutableMapOf()) {   
    fun includesTitle(title: String) { ... }
    fun retrieveAndRemove(title: String): Book? { ... }
    fun addBook(title: String, book: Book) { ... }
}

Conclusion

Caches should be functional and intelligent, allowing for effective management of invalidation. General-purpose caches are best suited for low-level objects like operating systems, files, and streams, while domain objects should not be cached.

Credits

• Code Smell 49 - Caches by Maximiliano Contieri

• Code Duplication

• Maintainability

• Don't Repeat Yourself

Solution

1. Find repeated patterns (not repeated code).

2. Create an abstraction.

3. Parametrize abstraction calls.

4. Use composition and avoid inheritance.

5. Unit test the new abstraction.

Sample Code

Wrong

class WordProcessor(var text: String = "") {
    fun replaceText(patternToFind: String, textToReplace: String) {
        text = "<<< ${text.replace(patternToFind, textToReplace} >>>"
    }
}

class Obfuscator(var text: String = "") {
    fun obfuscate(patternToFind: String, textToReplace: String) {
        text = text.lowercase().replace(patternToFind, textToReplace)
    }
}

Right

class TextReplacer {
    fun replace(
        patternToFind: String,
        textToReplace: String,
        subject: String,
        replaceFunction: (String, String, String) -> String,
        postProcessClosure: (String) -> String
    ): String =
        replaceFunction(patternToFind, textToReplace, subject)
            .let(postProcessClosure)
}

class WordProcessor(private var text: String = "") {
    fun replaceText(patternToFind: String, textToReplace: String) {
        text = TextReplacer()
            .replace(
                patternToFind,
                textToReplace,
                text,
                replaceFunction = { pattern, replace, subject ->
                    subject.replace(pattern, replace)
                },
                postProcessClosure = { "<<< $it >>>" }
            )
    }
}

class Obfuscator(private var text: String = "") {
    fun obfuscate(patternToFind: String, textToReplace: String) {
        text = TextReplacer()
            .replace(
                patternToFind,
                textToReplace,
                text,
                replaceFunction = { pattern, replace, subject ->
                    subject.replace(pattern, replace, ignoreCase = true)
                },
                postProcessClosure = { it.lowercase() }
            )
    }
}

Conclusion

Repeated code is always a smell. Copying and pasting code is always a shame. With our refactoring tools, we need to accept the challenge of removing duplication and trust our tests as a safety net.

Credits

• Code Smell 46 - Repeated Code by Maximiliano Contieri

• Missed Polymorphism
• Coupling
• IFs / Type check Polluting.
• Names are coupled to types.

Solutions

1. Rename methods after what they do.
2. Favor polymorphism.

Sample Code

Wrong

class Array {
    fun arraySort() { ... }
}

class List {
    fun listSort() { ... }
}

class Set {
    fun setSort() { ... }
}

Right

interface Sortable {
    fun sort()
}

class Array : Sortable {
    override fun sort() { ... }
}

class List : Sortable {
    override fun sort() { ... }
}

class Set : Sortable {
    override fun sort() { ... }
}

Conclusion

Naming is very important. We need to name concepts after what they do, not after accidental types.

Credits

• Code Smell 45 - Not Polymorphic by Maximiliano Contieri

• Bad Models
• Coupling
• Liskov Substitution Violation
• Method overriding
• Mapper fault

Solution

1. Subclasses should be specializations.
2. Refactor Hierarchies.
3. Favor Composition.
4. Leaf classes should be concrete.
5. Not-leaf classes should be abstract.

Sample Code

Wrong

class Stack<T> : ArrayList<T>() {
    fun push(value: T) { … }
    fun pop(): T { … }
}
// Stack does not behave Like an ArrayList
// besides pop, push, top it also implements (or overrides) get, set,
// add, remove and clear stack elements can be arbitrary accessed

// both classes are concrete

Right

abstract class Collection {
    abstract fun size(): Int
}

class Stack<out T> : Collection() {
    private val contents = ArrayList<T>()

    fun push(value: Any) { ... }

    fun pop(): Any? { ... }

    override fun size() = contents.size
}

class ArrayList : Collection() {
    override fun size(): Int { ... }
}

Conclusion

Accidental sub-classification is the first obvious advantage for junior developers.

More mature ones find composition opportunities instead.

Composition is dynamic, multiple, pluggable, more testable, more maintainable, and less coupled than inheritance.

Only subclassify an entity if it follows the relationship behaves like.

After subclassing, the parent class should be abstract.

Java made this mistake, and they're regretting it until now. Let's do better than Java 😁

Credits

• Code Smell 43 - Concrete Classes Subclassified by Maximiliano Contieri

Problem

• Readability

• Maintainability

• Testability

• Intention Revealing

Solution

1. Use regular expressions just for string validation.

2. If you need to manipulate objects, don't make them strings.

Sample Code

Wrong

val regex = "^\\+(?:[0-9a-zA-Z][– -]?){6,14}[0-9a-zA-Z]$".toRegex()

Right

val prefix = """\+"""
val digit = "[0-9a-zA-Z]"
val space = "[– -]"
val phoneRegex = "^$prefix(?:$digit$space?){6,14}$digit$".toRegex()

Conclusion

Regular expressions are a great tool for string validation. We must use them in a declarative way and just for strings.

Names are very important to understand pattern meanings.

If we need to manipulate objects or hierarchies, we should do it in an object way.

Unless we have a conclusive benchmark of impressive performance improvement.

Credits

• Code Smell 41 - Regular Expression Abusers by Maximiliano Contieri

• Implemental Naming
• Meaningless names
• Broken MAPPER and Bijection to real-world entities.

Solution

1. Choose meaningful names.
2. Find metaphors.
3. Avoid words like abstract, base, generic, helper, data, info, etc.
4. Use rules for naming.

Sample Code

Wrong

class Repository {
    // ...
}

class MeetingCollection {
    // ...
}

class AccountsComposite {
    // ...
}

class NoteArray {
    // ...
}

class LogCollector {
    // ...
}

abstract class SearcherBase {
    // ...
}

abstract class AbstractTransportation {
    // ...
}

Right

class Schedule {
    // ...
}

class Portfolio {
    // ...
}

class NoteBook {
    // ...
}

class Journal {
    // ...
}

class Vehicle {
    // ...
}

Conclusion

Finding names is the last thing we should do in our designs. Unless we have a clear business understanding, good names emerge at the end after defining behavior and protocol boundaries.

Credits

• Code Smell 38 - Abstract Names by Maximiliano Contieri

• Sub-classification for code reuse purposes.
• Liskov substitution violation (SOLID principle).
• Possible subclass overrides.

Solution

1. Favor composition
2. Avoid subclassifying attributes.
3. Extract behavior to separate objects.

Sample Code

Wrong

abstract class ElectronicDevice(protected val battery: Battery)

abstract class IDevice(
    battery: Battery,
    protected val operatingSystem: OperatingSystem
) : ElectronicDevice(battery)

class IPad(
    battery: Battery,
    ios: OperatingSystem
) : IDevice(battery, ios)

class IPhone(
    battery: Battery,
    ios: OperatingSystem,
    val phoneModule: PhoneModule
) : IDevice(battery, ios)

Right

interface ElectronicDevice {
    //...
}

interface PhoneCommunication {
    //...
}

class IPad(
    private val battery: Battery,
    private val operatingSystem: OperatingSystem
) : ElectronicDevice {
    // Implement iPad-specific functionality here
}

class IPhone(
    private val battery: Battery,
    private val operatingSystem: OperatingSystem,
    private val phoneModule: PhoneModule
) : ElectronicDevice, PhoneCommunication {
    // Implement iPhone-specific functionality here
}

Conclusion

Protected attributes are yet another tool we should use carefully. Every decision is a smell, and we should be very cautious with attributes and inheritance.

Credits

• Code Smell 37 - Protected Attributes by Maximiliano Contieri