In the world of software development, there often arises a need to handle business logic depending on the values of input parameters. At first glance, one could address this requirement using simple if-else or when constructs, but such implementations can lead to code that is difficult to read and maintain. It conflicts with the principles of object-oriented programming, and extending this logic often requires modifying existing code. In this article, we will explore how to effectively implement the Strategy design pattern in the Kotlin programming language using the Spring framework. This approach allows us to create easily extensible and maintainable applications while adhering to SOLID principles. The Strategy pattern is a behavioral design pattern that enables selecting an algorithm’s behavior at runtime. It defines a family of algorithms, encapsulates each one, and makes them interchangeable. The Strategy pattern promotes the Open/Closed Principle by allowing new strategies to be added without modifying existing code, which aligns perfectly with the goals of clean and maintainable software architecture. The Problem with Using if-else Consider the following code, which is an example of an anti-pattern that uses when to handle different screens: fun getScreen(viewId: String): ScreenResponse {
   when (viewId) {
       "cardScreen" -> TODO("Implement logic for cardScreen")
       "infoScreen" -> TODO("Implement logic for infoScreen")
       "accountScreen" -> TODO("Implement logic for accountScreen")
       else -> throw RuntimeException("Filler for $viewId not found")
   }
} As we can see, this code can quickly grow in complexity, making it difficult to manage and expand. When a new screen needs to be added, the developer is forced to modify existing code, which violates the Open/Closed Principle (OCP) from the SOLID design principles—software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. Solution with the Strategy Pattern A more elegant solution is to use the Strategy pattern. We can create several services, each responsible for a specific screen. This allows us to add new screens by simply creating new services while leaving the existing code unchanged. Application Architecture Let’s consider a microservice that returns an SDUI (Server-Driven User Interface) screen to the front end. The client requests the necessary screen by its identifier, and the server returns the corresponding business data. @RestController
class ScreenController(
   private val screenService: ScreenService,
) {
   @GetMapping
   fun getScreen(@RequestParam viewId: String): ScreenResponse = screenService.getScreen(viewId)
} Defining the Interface To implement the Strategy pattern, we begin by defining an interface Filler, which will contain a method for filling the screen: interface Filler {
   fun fill(): ScreenResponse
} Implementing Concrete Strategies Next, we create classes that implement this interface for each screen: @Service
class CardFiller : Filler {
   override fun fill(): ScreenResponse {
       return ScreenResponse("Data for the card screen") // Implement logic for the card screen
   }
}

@Service
class AccountFiller : Filler {
   override fun fill(): ScreenResponse {
       return ScreenResponse("Data for the account screen") // Implement logic for the account screen
   }
}

@Service
class InfoFiller : Filler {
   override fun fill(): ScreenResponse {
       return ScreenResponse("Data for the owner information screen") // Implement logic for the info screen
   }
} Creating the Main Service The main service ScreenService, which will use our concrete strategies, looks as follows. We will store them in a Map, where the key is the screen identifier and the value is the strategy object: @Service
class ScreenService(
   private val fillerMap: Map<String, Filler> // Injection of all implementations of the Filler interface
) {
   fun getScreen(viewId: String): ScreenResponse {
       val filler = fillerMap[viewIDToFiller[viewId]]
       return filler?.fill() ?: throw RuntimeException("Filler for $viewId not found")
   }

   private companion object {
       val viewIDToFiller = mapOf(
           "cardScreen" to "cardFiller",
           "infoScreen" to "infoFiller",
           "accountScreen" to "accountFiller"
       )
   }
} How It Works In this code, we inject all implementations of the Filler interface into the ScreenService. We use a Map for quick access to the desired strategy using the screen identifier as the key. This makes it very easy to add new strategies: just create a new class that implements the Filler interface and add a corresponding entry in viewIDToFiller. Benefits of the Strategy Pattern By employing the Strategy pattern, we achieve a high degree of modularity and separation of concerns, allowing for easier testing, maintenance, and future expansion of functionality. Each strategy is isolated in its own class, which makes it simpler to change or add functionality without affecting other parts of the application. This results in a more robust and adaptable codebase. Conclusion Utilizing the Strategy pattern in conjunction with powerful tools like Kotlin and Spring allows for a significant simplification of code while enhancing its flexibility and extensibility. Instead of manipulating complex if-else or when constructs, we organize business logic into separate services, each responsible for its part of the application. Thus, when adding a new screen, we only need to create a new service and make minimal changes to the existing infrastructure. This practice aligns with object-oriented programming principles and promotes the development of cleaner, more maintainable code. Considering all the flexibility provided by Spring, the implementation of the Strategy pattern becomes not only straightforward but also an effective practice for creating high-quality software solutions. In the world of software development, there often arises a need to handle business logic depending on the values of input parameters. At first glance, one could address this requirement using simple if-else or when constructs, but such implementations can lead to code that is difficult to read and maintain. It conflicts with the principles of object-oriented programming, and extending this logic often requires modifying existing code. In this article, we will explore how to effectively implement the Strategy design pattern in the Kotlin programming language using the Spring framework. This approach allows us to create easily extensible and maintainable applications while adhering to SOLID principles. if-else when The Strategy pattern is a behavioral design pattern that enables selecting an algorithm’s behavior at runtime. It defines a family of algorithms, encapsulates each one, and makes them interchangeable. The Strategy pattern promotes the Open/Closed Principle by allowing new strategies to be added without modifying existing code, which aligns perfectly with the goals of clean and maintainable software architecture. The Problem with Using if-else if-else Consider the following code, which is an example of an anti-pattern that uses when to handle different screens: when fun getScreen(viewId: String): ScreenResponse {
   when (viewId) {
       "cardScreen" -> TODO("Implement logic for cardScreen")
       "infoScreen" -> TODO("Implement logic for infoScreen")
       "accountScreen" -> TODO("Implement logic for accountScreen")
       else -> throw RuntimeException("Filler for $viewId not found")
   }
} fun getScreen(viewId: String): ScreenResponse {
   when (viewId) {
       "cardScreen" -> TODO("Implement logic for cardScreen")
       "infoScreen" -> TODO("Implement logic for infoScreen")
       "accountScreen" -> TODO("Implement logic for accountScreen")
       else -> throw RuntimeException("Filler for $viewId not found")
   }
} As we can see, this code can quickly grow in complexity, making it difficult to manage and expand. When a new screen needs to be added, the developer is forced to modify existing code, which violates the Open/Closed Principle (OCP) from the SOLID design principles—software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. Solution with the Strategy Pattern A more elegant solution is to use the Strategy pattern. We can create several services, each responsible for a specific screen. This allows us to add new screens by simply creating new services while leaving the existing code unchanged. Application Architecture Let’s consider a microservice that returns an SDUI (Server-Driven User Interface) screen to the front end. The client requests the necessary screen by its identifier, and the server returns the corresponding business data. @RestController
class ScreenController(
   private val screenService: ScreenService,
) {
   @GetMapping
   fun getScreen(@RequestParam viewId: String): ScreenResponse = screenService.getScreen(viewId)
} @RestController
class ScreenController(
   private val screenService: ScreenService,
) {
   @GetMapping
   fun getScreen(@RequestParam viewId: String): ScreenResponse = screenService.getScreen(viewId)
} Defining the Interface To implement the Strategy pattern, we begin by defining an interface Filler , which will contain a method for filling the screen: Filler interface Filler {
   fun fill(): ScreenResponse
} interface Filler {
   fun fill(): ScreenResponse
} Implementing Concrete Strategies Next, we create classes that implement this interface for each screen: @Service
class CardFiller : Filler {
   override fun fill(): ScreenResponse {
       return ScreenResponse("Data for the card screen") // Implement logic for the card screen
   }
}

@Service
class AccountFiller : Filler {
   override fun fill(): ScreenResponse {
       return ScreenResponse("Data for the account screen") // Implement logic for the account screen
   }
}

@Service
class InfoFiller : Filler {
   override fun fill(): ScreenResponse {
       return ScreenResponse("Data for the owner information screen") // Implement logic for the info screen
   }
} @Service
class CardFiller : Filler {
   override fun fill(): ScreenResponse {
       return ScreenResponse("Data for the card screen") // Implement logic for the card screen
   }
}

@Service
class AccountFiller : Filler {
   override fun fill(): ScreenResponse {
       return ScreenResponse("Data for the account screen") // Implement logic for the account screen
   }
}

@Service
class InfoFiller : Filler {
   override fun fill(): ScreenResponse {
       return ScreenResponse("Data for the owner information screen") // Implement logic for the info screen
   }
} Creating the Main Service The main service ScreenService , which will use our concrete strategies, looks as follows. We will store them in a Map , where the key is the screen identifier and the value is the strategy object: ScreenService Map @Service
class ScreenService(
   private val fillerMap: Map<String, Filler> // Injection of all implementations of the Filler interface
) {
   fun getScreen(viewId: String): ScreenResponse {
       val filler = fillerMap[viewIDToFiller[viewId]]
       return filler?.fill() ?: throw RuntimeException("Filler for $viewId not found")
   }

   private companion object {
       val viewIDToFiller = mapOf(
           "cardScreen" to "cardFiller",
           "infoScreen" to "infoFiller",
           "accountScreen" to "accountFiller"
       )
   }
} @Service
class ScreenService(
   private val fillerMap: Map<String, Filler> // Injection of all implementations of the Filler interface
) {
   fun getScreen(viewId: String): ScreenResponse {
       val filler = fillerMap[viewIDToFiller[viewId]]
       return filler?.fill() ?: throw RuntimeException("Filler for $viewId not found")
   }

   private companion object {
       val viewIDToFiller = mapOf(
           "cardScreen" to "cardFiller",
           "infoScreen" to "infoFiller",
           "accountScreen" to "accountFiller"
       )
   }
} How It Works In this code, we inject all implementations of the Filler interface into the ScreenService . We use a Map for quick access to the desired strategy using the screen identifier as the key. This makes it very easy to add new strategies: just create a new class that implements the Filler interface and add a corresponding entry in viewIDToFiller . Filler ScreenService Map Filler viewIDToFiller Benefits of the Strategy Pattern By employing the Strategy pattern, we achieve a high degree of modularity and separation of concerns, allowing for easier testing, maintenance, and future expansion of functionality. Each strategy is isolated in its own class, which makes it simpler to change or add functionality without affecting other parts of the application. This results in a more robust and adaptable codebase. Conclusion Utilizing the Strategy pattern in conjunction with powerful tools like Kotlin and Spring allows for a significant simplification of code while enhancing its flexibility and extensibility. Instead of manipulating complex if-else or when constructs, we organize business logic into separate services, each responsible for its part of the application. if-else when Thus, when adding a new screen, we only need to create a new service and make minimal changes to the existing infrastructure. This practice aligns with object-oriented programming principles and promotes the development of cleaner, more maintainable code. Considering all the flexibility provided by Spring, the implementation of the Strategy pattern becomes not only straightforward but also an effective practice for creating high-quality software solutions.

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Implementation of the Strategy Pattern in Kotlin and Spring

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Infrastructure as Code – Whose Responsibility Is It?

Rules of Thumb for Software Engineering

11 Commandments Of Smart Contract Designing

12 Methods of Improving Your Monolith Before Making the Jump to Microservices

3 Elements of Omnichannel CX Excellence

2023 Graphic Design Trends: A Look into the Future of Visual Design

Infrastructure as Code – Whose Responsibility Is It?

Rules of Thumb for Software Engineering

11 Commandments Of Smart Contract Designing

12 Methods of Improving Your Monolith Before Making the Jump to Microservices

3 Elements of Omnichannel CX Excellence

2023 Graphic Design Trends: A Look into the Future of Visual Design

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps