Kotlin

The Command Design Pattern is a behavioral design pattern that encapsulates a request as an independent object, storing all necessary information to process the request. This pattern is especially beneficial in scenarios where you need to:

• Separate the initiator of the request (the sender) from the object responsible for executing it (the receiver).
• Implement functionality for undoing and redoing operations.
• Facilitate the queuing, logging, or scheduling of requests for execution.

Let’s embark on a journey to understand the Command design pattern, its purpose, and how we can implement it in Kotlin. Along the way, I’ll share practical examples and insights to solidify our understanding.

Command Design Pattern

At its core, the Command Design Pattern decouples the sender (the one making a request) from the receiver (the one handling the request). Instead of calling methods directly, the sender issues a command that encapsulates the details of the request. This way, the sender only knows about the command interface and not the specific implementation.

In short,

• Sender: Issues commands.
• Command: Encapsulates the request.
• Receiver: Executes the request.

Structure of the Command Pattern

Before we dive into code, let’s see the primary components of this pattern:

1. Command: An interface or abstract class defining a single method, execute().
2. ConcreteCommand: Implements the Command interface and encapsulates the actions to be performed.
3. Receiver: The object that performs the actual work.
4. Invoker: The object that triggers the command’s execution.
5. Client: The entity that creates and configures commands.

Command Pattern Implementation

Imagine a smart home system, similar to Google Home, where you can control devices like turning lights on/off or playing music. This scenario can be a great example to demonstrate the implementation of the Command design pattern.

// Command.kt
interface Command {
    fun execute()
}

Create Receivers

The receiver performs the actual actions. For simplicity, we’ll create two receivers: Light and MusicPlayer.

// Light.kt
class Light {
    fun turnOn() {
        println("Light is turned ON")
    }

    fun turnOff() {
        println("Light is turned OFF")
    }
}

// MusicPlayer.kt
class MusicPlayer {
    fun playMusic() {
        println("Music is now playing")
    }

    fun stopMusic() {
        println("Music is stopped")
    }
}

Create Concrete Commands

Each concrete command encapsulates a request to the receiver.

// LightCommands.kt
class TurnOnLightCommand(private val light: Light) : Command {
    override fun execute() {
        light.turnOn()
    }
}

class TurnOffLightCommand(private val light: Light) : Command {
    override fun execute() {
        light.turnOff()
    }
}

// MusicCommands.kt
class PlayMusicCommand(private val musicPlayer: MusicPlayer) : Command {
    override fun execute() {
        musicPlayer.playMusic()
    }
}

class StopMusicCommand(private val musicPlayer: MusicPlayer) : Command {
    override fun execute() {
        musicPlayer.stopMusic()
    }
}

Create the Invoker

The invoker doesn’t know the details of the commands but can execute them. In this case, our remote is the center of home automation and can control everything.

// RemoteControl.kt
class RemoteControl {
    private val commands = mutableListOf<Command>()

    fun setCommand(command: Command) {
        commands.add(command)
    }

    fun executeCommands() {
        commands.forEach { it.execute() }
        commands.clear()
    }
}

Client Code

Now, let’s create the client code to see the pattern in action.

// Main.kt
fun main() {
    // Receivers
    val light = Light()
    val musicPlayer = MusicPlayer()

    // Commands
    val turnOnLight = TurnOnLightCommand(light)
    val turnOffLight = TurnOffLightCommand(light)
    val playMusic = PlayMusicCommand(musicPlayer)
    val stopMusic = StopMusicCommand(musicPlayer)

    // Invoker
    val remoteControl = RemoteControl()

    // Set and execute commands
    remoteControl.setCommand(turnOnLight)
    remoteControl.setCommand(playMusic)
    remoteControl.executeCommands() // Executes: Light ON, Music Playing

    remoteControl.setCommand(turnOffLight)
    remoteControl.setCommand(stopMusic)
    remoteControl.executeCommands() // Executes: Light OFF, Music Stopped
}

Here,

Command Interface: The Command interface ensures uniformity. Whether it’s turning on a light or playing music, all commands implement execute().

Receivers: The Light and MusicPlayer classes perform the actual work. They are decoupled from the invoker.

Concrete Commands: Each command bridges the invoker and the receiver. This encapsulation allows us to add new commands easily without modifying the existing code (We will see it shortly after this).

Invoker: The RemoteControl acts as a controller. It queues and executes commands, providing flexibility for batch operations.

Client Code: We bring all components together, creating a functional smart home system.

Enhancing the Pattern

If we wanted to add undo functionality, we could introduce an undo() method in the Command interface. Each concrete command would then implement the reversal logic. For example:

interface Command {
    fun execute()
    fun undo()
}

class TurnOnLightCommand(private val light: Light) : Command {
    override fun execute() {
        light.turnOn()
    }

    override fun undo() {
        light.turnOff()
    }
}

Advantages of the Command Pattern

Flexibility: Adding new commands doesn’t affect existing code, adhering to the Open/Closed Principle.

Decoupling: The sender (invoker) doesn’t need to know about the receiver’s implementation.

Undo/Redo Support: With a little modification, you can store executed commands and reverse their actions.

Command Queues: Commands can be queued for delayed execution.

Disadvantages

Complexity: For simple use cases, this pattern may feel overengineered due to the additional classes.

Memory Overhead: Keeping a history of commands may increase memory usage.

Conclusion

The Command design pattern is a powerful tool in a developer’s toolkit, allowing us to build systems that are flexible, decoupled, and easy to extend. Kotlin’s concise and expressive syntax makes implementing this pattern a breeze, ensuring both clarity and functionality.

I hope this deep dive has demystified the Command pattern for you. Now it’s your turn — experiment with the code, tweak it, and see how you can apply it in your own projects..! 

Happy coding..! 🚀

Have you ever had to manage an object’s behavior based on its state? You might have ended up writing a series of if-else or when statements to handle different scenarios. Sound familiar? (Especially if you’re working with Android and Kotlin!) If so, it’s time to explore the State Design Pattern—a structured approach to simplify your code, enhance modularity, and improve maintainability.

In this blog, we’ll explore the State Design Pattern in depth, focusing on its use in Kotlin. We’ll discuss its purpose, the benefits it offers, and provide detailed examples with clear explanations. By the end, you’ll have the knowledge and confidence to incorporate it seamlessly into your projects.

State Design Pattern

The State Design Pattern is part of the behavioral design patterns group, focusing on managing an object’s dynamic behavior based on its current state. As described in the Gang of Four’s book, this pattern “enables an object to modify its behavior as its internal state changes, giving the impression that its class has changed.” In short, it allows an object to alter its behavior depending on its internal state.

Key Features of the State Pattern

• State Encapsulation: Each state is encapsulated in its own class.
• Behavioral Changes: Behavior changes dynamically as the object’s state changes.
• No Conditionals: It eliminates long if-else or when chains by using polymorphism.

Structure of the State Design Pattern

State pattern encapsulates state-specific behavior into separate classes and delegates state transitions to these objects. Here’s a breakdown of its structure:

State Interface

The State Interface defines the methods that each state will implement. It provides a common contract for all concrete states.

interface State {
    fun handle(context: Context)
}

Here,

• The State interface declares a single method, handle(context: Context), which the Context calls to delegate behavior.
• Each concrete state will define its behavior within this method.

Concrete States

The Concrete States implement the State interface. Each represents a specific state and its associated behavior.

class ConcreteStateA : State {
    override fun handle(context: Context) {
        println("State A: Handling request and transitioning to State B")
        context.setState(ConcreteStateB()) // Transition to State B
    }
}

class ConcreteStateB : State {
    override fun handle(context: Context) {
        println("State B: Handling request and transitioning to State A")
        context.setState(ConcreteStateA()) // Transition to State A
    }
}

• ConcreteStateA and ConcreteStateB implement the State interface and define their unique behavior.
• Each state determines the next state and triggers a transition using the context.setState() method.

Context

The Context is the class that maintains a reference to the current state and delegates behavior to it.

class Context {
    private var currentState: State? = null

    fun setState(state: State) {
        currentState = state
        println("Context: State changed to ${state::class.simpleName}")
    }

    fun request() {
        currentState?.handle(this) ?: println("Context: No state is set")
    }
}

• The Context class holds a reference to the current state via currentState.
• The setState() method updates the current state and logs the transition.
• The request() method delegates the action to the current state’s handle() method.

Test the Implementation

Finally, we can create a main function to test the transitions between states.

fun main() {
    val context = Context()

    // Set initial state
    context.setState(ConcreteStateA())

    // Trigger behavior and transition between states
    context.request() // State A handles and transitions to State B
    context.request() // State B handles and transitions to State A
    context.request() // State A handles and transitions to State B
}

Output

Context: State changed to ConcreteStateA
State A: Handling request and transitioning to State B
Context: State changed to ConcreteStateB
State B: Handling request and transitioning to State A
Context: State changed to ConcreteStateA
State A: Handling request and transitioning to State B
Context: State changed to ConcreteStateB

How These Components Work Together

1. The Context is the central point of interaction for the client code. It contains a reference to the current state.
2. The State Interface ensures that all states adhere to a consistent set of behaviors.
3. The Concrete States implement specific behavior for the Context and may trigger transitions to other states.
4. When a client invokes a method on the Context, the Context delegates the behavior to the current state, which executes the appropriate logic.

Real-Time Use Cases

Game Development

The State Design Pattern is widely used in game development. A game character can exist in various states, such as healthy, surviving, or dead. In the healthy state, the character can attack enemies using different weapons. When the character enters the surviving state, its health becomes critical. Once the health reaches zero, the character transitions into the dead state, signaling the end of the game.

Now, let’s first explore how we could implement this use case without using the State Design Pattern, and then compare it with an implementation using the State Pattern for better understanding. This can be done using a series of if-else conditional checks, as demonstrated in the following code snippets.

Player Class

class Player {
    fun attack() {
        println("Attack")
    }

    fun fireBomb() {
        println("Fire Bomb")
    }

    fun fireGunblade() {
        println("Fire Gunblade")
    }

    fun fireLaserPistol() {
        println("Laser Pistol")
    }

    fun firePistol() {
        println("Fire Pistol")
    }

    fun survive() {
        println("Surviving!")
    }

    fun dead() {
        println("Dead! Game Over")
    }
}

Now let us define our game context class which defines the different actions conditionally depends on the state of the player.

GameContext Class (Without State Pattern)

class GameContext {
    private val player = Player()

    fun gameAction(state: String) {
        when (state) {
            "healthy" -> {
                player.attack()
                player.fireBomb()
                player.fireGunblade()
                player.fireLaserPistol()
            }
            "survival" -> {
                player.survive()
                player.firePistol()
            }
            "dead" -> {
                player.dead()
            }
            else -> {
                println("Invalid state")
            }
        }
    }
}

In this implementation of GameContext, we’re using a when block (or even if-else statements) to handle the state. While this approach works well for smaller examples, it can become harder to maintain and less scalable as more states and behaviors are added.

Applying the State Design Pattern

To eliminate the need for multiple conditional checks, let’s refactor the code using the State Design Pattern. We will define separate state classes for each state, and the GameContext will delegate the actions to the appropriate state object.

Define the State Interface

interface PlayerState {
    fun performActions(player: Player)
}

Implement Concrete States

Now, we’ll create concrete state classes for each state: HealthyState, SurvivalState, and DeadState.

class HealthyState : PlayerState {
    override fun performActions(player: Player) {
        player.attack()
        player.fireBomb()
        player.fireGunblade()
        player.fireLaserPistol()
    }
}

class SurvivalState : PlayerState {
    override fun performActions(player: Player) {
        player.survive()
        player.firePistol()
    }
}

class DeadState : PlayerState {
    override fun performActions(player: Player) {
        player.dead()
    }
}

Modify the GameContext Class

Finally, the GameContext class will hold a reference to the current state and delegate the action calls to that state.

class GameContext {
    private val player = Player()
    private var state: PlayerState = HealthyState() // Default state

    fun setState(state: PlayerState) {
        this.state = state
    }

    fun gameAction() {
        state.performActions(player)
    }
}

Testing the State Design Pattern

Now, let’s demonstrate how we can switch between different states and let the player perform actions based on the current state:

fun main() {
    val gameContext = GameContext()

    println("Player in Healthy state:")
    gameContext.gameAction() // Perform actions in Healthy state

    println("\nPlayer in Survival state:")
    gameContext.setState(SurvivalState())
    gameContext.gameAction() // Perform actions in Survival state

    println("\nPlayer in Dead state:")
    gameContext.setState(DeadState())
    gameContext.gameAction() // Perform actions in Dead state
}

Output

Player in Healthy state:
Attack
Fire Bomb
Fire Gunblade
Laser Pistol

Player in Survival state:
Surviving!
Fire Pistol

Player in Dead state:
Dead! Game Over

Let’s see what benefits we get by using the State Pattern in this case.

• Cleaner Code: The GameContext class no longer contains any conditionals. The logic is moved to the state classes, making it easier to manage and extend.
• Modular: Each state is encapsulated in its own class, which improves maintainability. If you need to add new states, you just need to implement a new PlayerState class.
• Extensible: New actions or states can be added without modifying the existing code. You simply create new state classes for additional behaviors.

Before generalizing the benefits of the State Pattern, let’s look at one more use case, which is in a document editor.

A Document Workflow

We’ll create a simple document editor. A document can be in one of three states:

1. Draft
2. Moderation
3. Published

The actions allowed will depend on the state:

• In Draft, you can edit or submit for review.
• In Moderation, you can approve or reject the document.
• In Published, no changes are allowed.

Without further delay, let’s implement it.

Define a State Interface

The state interface defines the contract for all possible states. Each state will implement this interface.

// State.kt
interface State {
    fun edit(document: Document)
    fun submitForReview(document: Document)
    fun publish(document: Document)
}

Create Concrete State Classes

Each state class represents a specific state and provides its own implementation of the state behavior.

Draft State

// DraftState.kt
class DraftState : State {
    override fun edit(document: Document) {
        println("Editing the document...")
    }

    override fun submitForReview(document: Document) {
        println("Submitting the document for review...")
        document.changeState(ModerationState()) // Transition to Moderation
    }

    override fun publish(document: Document) {
        println("Cannot publish a document in draft state.")
    }
}

Moderation State

// ModerationState.kt
class ModerationState : State {
    override fun edit(document: Document) {
        println("Cannot edit a document under moderation.")
    }

    override fun submitForReview(document: Document) {
        println("Document is already under review.")
    }

    override fun publish(document: Document) {
        println("Publishing the document...")
        document.changeState(PublishedState()) // Transition to Published
    }
}

Published State

// PublishedState.kt
class PublishedState : State {
    override fun edit(document: Document) {
        println("Cannot edit a published document.")
    }

    override fun submitForReview(document: Document) {
        println("Cannot submit a published document for review.")
    }

    override fun publish(document: Document) {
        println("Document is already published.")
    }
}

Define the Context Class

The context class represents the object whose behavior changes with its state. It maintains a reference to the current state.

// Document.kt
class Document {
    private var state: State = DraftState() // Initial state

    fun changeState(newState: State) {
        state = newState
        println("Document state changed to: ${state.javaClass.simpleName}")
    }

    fun edit() = state.edit(this)
    fun submitForReview() = state.submitForReview(this)
    fun publish() = state.publish(this)
}

Test the Implementation

Finally, we can create a main function to test how our document transitions between states.

// Main.kt
fun main() {
    val document = Document()

    // Current state: Draft
    document.edit()
    document.submitForReview()

    // Current state: Moderation
    document.edit()
    document.publish()

    // Current state: Published
    document.submitForReview()
    document.edit()
}

Output

Editing the document...
Submitting the document for review...
Document state changed to: ModerationState
Cannot edit a document under moderation.
Publishing the document...
Document state changed to: PublishedState
Cannot submit a published document for review.
Cannot edit a published document.

Benefits of Using the State Design Pattern

• Cleaner Code: Behavior is encapsulated in state-specific classes, eliminating conditionals.
• Scalability: Adding new states is straightforward—just implement the State interface.
• Encapsulation: Each state manages its behavior, reducing the responsibility of the context class.
• Dynamic Behavior: The object’s behavior changes at runtime by switching states.

When Should You Use the State Pattern?

The State Pattern is ideal when:

• An object’s behavior depends on its state.
• You have complex conditional logic based on state.
• States frequently change, and new states may be added.

However, avoid using it if:

• Your application has only a few states with minimal behavior.
• The state transitions are rare or do not justify the overhead of additional classes.

Conclusion

The State Design Pattern is an excellent way to achieve cleaner, more maintainable, and modular code. By isolating state-specific behaviors within their own classes, we can simplify the logic in our context objects and make our programs easier to extend.

In this blog, we examined the State Pattern through the lens of a document workflow and game development example. I hope this walkthrough provided clarity on implementing it in Kotlin. Now it’s your chance—experiment with this pattern in your own projects and experience its impact firsthand..!

Design patterns are a cornerstone of writing clean, maintainable, and reusable code. One of the more elegant patterns, the Chain of Responsibility (CoR), allows us to build a flexible system where multiple handlers can process a request in a loosely coupled manner. Today, we’ll dive deep into how this design pattern works and how to implement it in Kotlin.

What is the Chain of Responsibility Pattern?

The Chain of Responsibility design pattern is a behavioral design pattern that allows passing a request along a chain of handlers, where each handler has a chance to process the request or pass it along to the next handler in the chain. The main goal is to decouple the sender of a request from its receivers, giving multiple objects a chance to handle the request.

That means the CoR pattern allows multiple objects to handle a request without the sender needing to know which object handled it. The request is passed along a chain of objects (handlers), where each handler has the opportunity to process it or pass it to the next one.

Think of a company where a request, such as budget approval, must go through several levels of management. At each level, the manager can either address the request or escalate it to the next level.

Now imagine another situation: an employee submits a leave application. Depending on the duration of leave, it might need approval from different authorities, such as a team leader, department head, or higher management.

These scenarios capture the essence of the Chain of Responsibility design pattern, where a request is passed along a series of handlers, each with the choice to process it or forward it.

Why Use the Chain of Responsibility Pattern?

Before we delve into the structure and implementation of the Chain of Responsibility (CoR) pattern, let’s first understand why it’s important.

Consider a situation where multiple objects are involved in processing a request, and the handling varies depending on the specific conditions. For example, in online shopping platforms like Myntra or Amazon, or food delivery services such as Zomato or Swiggy, a customer might use a discount code or coupon. The system needs to determine if the code is valid or decide which discount should apply based on the circumstances.

This is where the Chain of Responsibility pattern becomes highly useful. Rather than linking the request to a specific handler, it enables the creation of a chain of handlers, each capable of managing the request in its unique way. This makes the system more adaptable, allowing developers to easily add, remove, or modify handlers without affecting the core logic.

So, the Chain of Responsibility pattern offers several advantages:

• Decouples the sender and receiver: The sender doesn’t need to know which object in the chain will handle the request.
• Simplifies the code: It eliminates complex conditionals and decision trees by delegating responsibility to handlers in the chain.
• Adds flexibility: New handlers can be seamlessly added to the chain without impacting the existing implementation.

We’ll look at the actual code and explore additional real-world examples shortly to make this concept even clearer.

Structure of the Chain of Responsibility Pattern

The Chain of Responsibility pattern consists of:

1. Handler Interface: Declares a method to process requests and optionally set the next handler.
2. Concrete Handlers: Implements the interface and processes the request.
3. Client Code: Creates and configures the chain.

Handler (Abstract Class or Interface)

Defines the interface for handling requests and the reference to the next handler in the chain.

abstract class Handler {
    protected var nextHandler: Handler? = null
    
    abstract fun handleRequest(request: String)
    
    fun setNextHandler(handler: Handler) {
        nextHandler = handler
    }
}

• This defines an interface for handling requests, usually with a method like handleRequest(). It may also have a reference to the next handler in the chain.
• The handler may choose to process the request or pass it on to the next handler.

ConcreteHandler

Implement the handleRequest() method to either process the request or pass it to the next handler.

class ConcreteHandlerA : Handler() {
    override fun handleRequest(request: String) {
        if (request == "A") {
            println("Handler A processed request: $request")
        } else {
            nextHandler?.handleRequest(request)
        }
    }
}

class ConcreteHandlerB : Handler() {
    override fun handleRequest(request: String) {
        if (request == "B") {
            println("Handler B processed request: $request")
        } else {
            nextHandler?.handleRequest(request)
        }
    }
}

• These are the actual handler classes that implement the handleRequest() method. Each concrete handler will either process the request or pass it to the next handler in the chain.
• If a handler is capable of processing the request, it does so; otherwise, it forwards the request to the next handler in the chain.

Client

Interacts only with the first handler in the chain, unaware of the specific handler processing the request.

fun main() {
    val handlerA = ConcreteHandlerA()
    val handlerB = ConcreteHandlerB()

    handlerA.setNextHandler(handlerB)
    
    // Client sends the request to the first handler
    handlerA.handleRequest("A") // Handler A processes the request
    handlerA.handleRequest("B") // Handler B processes the request
}

• The client sends the request to the first handler in the chain. The client does not need to know which handler will eventually process the request.

As we can see, this structure allows requests to pass through multiple handlers in the chain, with each handler having the option to process the request or delegate it.

Now, let’s roll up our sleeves and dive into real-world use case code.

Real-World Use Case

Now, let’s roll up our sleeves and dive into real-world use case code.

Handling Employee Request

Let’s revisit our employee leave request scenario, where we need to approve a leave request in a company. The leave request should be processed by different authorities depending on the amount of leave being requested. Here’s the hierarchy:

• Employee: Initiates the leave request by submitting it to their immediate supervisor or system.
• Manager (up to 5 days): Approves short leaves to handle minor requests efficiently.
• Director (up to 15 days): Approves extended leaves, ensuring alignment with organizational policies.
• HR (more than 15 days): Handles long-term leave requests, requiring policy compliance or special considerations.

Using the Chain of Responsibility, we can chain the approval process such that if one handler (e.g., Manager) cannot process the request, it is passed to the next handler (e.g., Director).

Define the Handler Interface

The handler interface is a blueprint for the handlers that will process requests. Each handler can either process the request or pass it along to the next handler in the chain.

// Create the Handler interface
interface LeaveRequestHandler {
    fun handleRequest(request: LeaveRequest)
}

In this case, the handleRequest function takes a LeaveRequest object, which holds the details of the leave request, and processes it.

Define the Request Object

The request object contains all the information related to the request. Here, we’ll create a simple LeaveRequest class.

// Create the LeaveRequest object
data class LeaveRequest(val employeeName: String, val numberOfDays: Int)

Create Concrete Handlers

Now, we’ll implement different concrete handlers for each authority: Manager, Director, and HR. Each handler will check if it can approve the leave request based on the number of days requested.

// Implement the Manager Handler
class Manager(private val nextHandler: LeaveRequestHandler? = null) : LeaveRequestHandler {
    override fun handleRequest(request: LeaveRequest) {
        if (request.numberOfDays <= 5) {
            println("Manager approved ${request.employeeName}'s leave for ${request.numberOfDays} days.")
        } else {
            nextHandler?.handleRequest(request)
        }
    }
}

// Implement the Director Handler
class Director(private val nextHandler: LeaveRequestHandler? = null) : LeaveRequestHandler {
    override fun handleRequest(request: LeaveRequest) {
        if (request.numberOfDays <= 15) {
            println("Director approved ${request.employeeName}'s leave for ${request.numberOfDays} days.")
        } else {
            nextHandler?.handleRequest(request)
        }
    }
}

// Implement the HR Handler
class HR : LeaveRequestHandler {
    override fun handleRequest(request: LeaveRequest) {
        println("HR approved ${request.employeeName}'s leave for ${request.numberOfDays} days.")
    }
}

Each handler checks whether the request can be processed. If it cannot, the request is passed to the next handler in the chain.

Set Up the Chain

Next, we’ll set up the chain of responsibility. We will link the handlers so that each handler knows who to pass the request to if it can’t handle it.

// Setup the chain
fun createLeaveApprovalChain(): LeaveRequestHandler {
    val hr = HR()
    val director = Director(hr)
    val manager = Manager(director)
    
    return manager // The chain starts with the Manager
}

• If the Manager can’t approve the leave (i.e., the request is for more than 5 days), it passes the request to the Director.
• If the Director can’t approve the leave (i.e., the request is for more than 15 days), it passes the request to HR, which will handle it.

Test the Chain of Responsibility

Now, let’s create a LeaveRequest and pass it through the chain.

fun main() {
    val leaveRequest = LeaveRequest("amol pawar", 10)
    
    val approvalChain = createLeaveApprovalChain()
    approvalChain.handleRequest(leaveRequest)
}

// OUTPUT

// Director approved amol pawar's leave for 10 days.

Now, let’s explore an E-Commerce Discount System using CoR.

Discount Handling in an E-Commerce System

Let’s imagine a scenario with platforms like Myntra, Flipkart, or Amazon, where we have different types of discounts:

• Coupon Discount (10% off)
• Member Discount (5% off)
• Seasonal Discount (15% off)

In this case, we’ll pass a request for a discount through a chain of handlers. Each handler checks if it can process the request or passes it to the next one in the chain.

Let’s now see how we can implement the Chain of Responsibility pattern in this case.

Define the Handler Interface

The handler interface will define a method handleRequest() that every concrete handler will implement.

// Handler Interface
interface DiscountHandler {
    fun setNext(handler: DiscountHandler): DiscountHandler
    fun handleRequest(amount: Double): Double
}

Here, the setNext() method will allow us to chain multiple handlers together, and handleRequest() will process the request.

Concrete Handlers

Let’s define the different discount handlers. Each one will check if it can handle the discount request. If it can’t, it will forward it to the next handler.

// Concrete Handler for Coupon Discount
class CouponDiscountHandler(private val discount: Double) : DiscountHandler {
    private var nextHandler: DiscountHandler? = null

    override fun setNext(handler: DiscountHandler): DiscountHandler {
        nextHandler = handler
        return handler
    }

    override fun handleRequest(amount: Double): Double {
        val discountedAmount = if (discount > 0) {
            println("Applying Coupon Discount: $discount%")
            amount - (amount * (discount / 100))
        } else {
            nextHandler?.handleRequest(amount) ?: amount
        }
        return discountedAmount
    }
}

// Concrete Handler for Member Discount
class MemberDiscountHandler(private val discount: Double) : DiscountHandler {
    private var nextHandler: DiscountHandler? = null

    override fun setNext(handler: DiscountHandler): DiscountHandler {
        nextHandler = handler
        return handler
    }

    override fun handleRequest(amount: Double): Double {
        val discountedAmount = if (discount > 0) {
            println("Applying Member Discount: $discount%")
            amount - (amount * (discount / 100))
        } else {
            nextHandler?.handleRequest(amount) ?: amount
        }
        return discountedAmount
    }
}

// Concrete Handler for Seasonal Discount
class SeasonalDiscountHandler(private val discount: Double) : DiscountHandler {
    private var nextHandler: DiscountHandler? = null

    override fun setNext(handler: DiscountHandler): DiscountHandler {
        nextHandler = handler
        return handler
    }

    override fun handleRequest(amount: Double): Double {
        val discountedAmount = if (discount > 0) {
            println("Applying Seasonal Discount: $discount%")
            amount - (amount * (discount / 100))
        } else {
            nextHandler?.handleRequest(amount) ?: amount
        }
        return discountedAmount
    }
}

Client Code

Now that we have defined our concrete handlers, let’s see how the client can set up the chain and make a request.

fun main() {
    // Creating discount handlers
    val couponHandler = CouponDiscountHandler(10.0) // 10% off
    val memberHandler = MemberDiscountHandler(5.0) // 5% off
    val seasonalHandler = SeasonalDiscountHandler(15.0) // 15% off

    // Chain the handlers
    couponHandler.setNext(memberHandler).setNext(seasonalHandler)

    // Client request
    val originalAmount = 1000.0
    val finalAmount = couponHandler.handleRequest(originalAmount)

    println("Final Amount after applying discounts: $finalAmount")
}

// OUTPUT

// Applying Coupon Discount: 10.0%
// Final Amount after applying discounts: 900.0

Here,

• Handlers: We define three concrete handlers, each responsible for applying a specific discount: coupon, member, and seasonal.
• Chaining: We chain the handlers together using setNext(). The chain is set up such that if one handler can’t process the request, it passes the request to the next handler.
• Request Processing: The client sends a request for the original amount (1000.0 in our example) to the first handler (couponHandler). If the handler can process the request, it applies the discount and returns the discounted amount. If it can’t, it forwards the request to the next handler.

But here’s the twist: what if we want to apply only the member discount? What will the output be, and how can we achieve this? Let’s see how we can do it. To achieve this, we need to set all other discounts to either 0 or negative. Only then will we get the exact output we want. 

Here, I’ll skip the actual code and just show the changes and the output.

    val couponHandler = CouponDiscountHandler(0.0) 
    val memberHandler = MemberDiscountHandler(5.0) // only applying 5% off
    val seasonalHandler = SeasonalDiscountHandler(-5.0) // 0 or negative 

    
    // Output 

    // Applying Member Discount: 5.0%
    // Final Amount after applying discounts: 950.0

Please note that this might seem a bit confusing, so let me clarify. In this example, we apply only one discount at a time. To achieve this, we set the other discounts to zero, ensuring that only the selected discount is applied. This is because we’ve set the starting handler to the coupon discount, which prevents the other discounts from being applied sequentially. As we often see on platforms like Flipkart and Amazon, only one coupon can typically be applied at a time.

However, this doesn’t mean that applying multiple coupons sequentially (i.e., applying all selected discounts at once) is impossible using the Chain of Responsibility (CoR) pattern. In fact, it can be achieved through the accumulation of discounts, where the total amount is updated after each sequential discount (e.g., coupon, member discount, seasonal discount). This allows us to apply all the discounts and calculate the final amount.

The sequential discount approach is particularly useful in the early stages of a business, when the goal is to attract more users or customers. In well-established e-commerce systems, however, only one discount is usually applied. In our case, we achieve this by setting the other discounts to either zero or a negative value.

Just to clarify, this explanation is a simplified scenario to help understand the concept. Real-world use cases often involve more complexities and variations. I hope this helps clear things up..!

Now, one more familiar use case that many of us have likely worked with in past projects is the Logging System.

Logging System

Let’s implement a logging system where log messages are passed through a chain of loggers. Each logger decides whether to handle the log or pass it along. We’ll include log levels: INFO, DEBUG, and ERROR.

Define a Base Logger Class

First, we’ll create an abstract Logger class. This will act as the base for all specific loggers.

abstract class Logger(private val level: Int) {

    private var nextLogger: Logger? = null

    // Set the next logger in the chain
    fun setNext(logger: Logger): Logger {
        this.nextLogger = logger
        return logger
    }

    // Handle the log request
    fun logMessage(level: Int, message: String) {
        if (this.level == level) {
            write(message)
            return                // To stop further propagation
        }
        nextLogger?.logMessage(level, message)
    }

    // Abstract method for handling the log
    protected abstract fun write(message: String)
}

Here,

• level: Defines the log level this logger will handle.
• nextLogger: Points to the next handler in the chain.
• setNext: Configures the next logger in the chain, enabling chaining.
• logMessage: Checks if the logger should process the message based on its level. If not, it delegates the task to the next logger in the chain.
• return: Why used return here..? The return is used to prevent the log message from being passed to the next logger after it has been processed. It ensures that once a logger handles the message, it won’t be forwarded further, avoiding redundant output.

Create Specific Logger Implementations

Let’s create concrete loggers for INFO, DEBUG, and ERROR levels.

class InfoLogger : Logger(1) {
    override fun write(message: String) {
        println("INFO: $message")
    }
}

class DebugLogger : Logger(2) {
    override fun write(message: String) {
        println("DEBUG: $message")
    }
}

class ErrorLogger : Logger(3) {
    override fun write(message: String) {
        println("ERROR: $message")
    }
}

• Each logger overrides the write method to handle messages at its respective log level.
• For instance, the InfoLogger handles logs with a level of 1, while higher levels (DEBUG or ERROR) are passed down the chain.

Setting Up the Chain

Now, let’s set up a chain of loggers: INFO → DEBUG → ERROR.

fun getLoggerChain(): Logger {
    val errorLogger = ErrorLogger()
    val debugLogger = DebugLogger()
    val infoLogger = InfoLogger()

    infoLogger.setNext(debugLogger).setNext(errorLogger)

    return infoLogger
}

• We instantiate the loggers and chain them together using setNext.
• The chain starts with InfoLogger and ends with ErrorLogger.

Using the Logger Chain

Now, let’s test our chain.

fun main() {
    val loggerChain = getLoggerChain()

    println("Testing Chain of Responsibility:")
    loggerChain.logMessage(1, "This is an info message.")
    loggerChain.logMessage(2, "This is a debug message.")
    loggerChain.logMessage(3, "This is an error message.")
}

Output

Testing Chain of Responsibility:
INFO: This is an info message.
DEBUG: This is a debug message.
ERROR: This is an error message.

Basically, what happens here is,

• A log with level 1 is processed by InfoLogger.
• A log with level 2 is handled by DebugLogger.
• A log with level 3 is processed by ErrorLogger.

If no logger in the chain can handle a request, it simply passes through without being processed.

Extending the Chain

What if we wanted to add more log levels, like TRACE? Easy..! Just implement a TraceLogger and link it to the chain without modifying the existing code.

class TraceLogger : Logger(0) {
    override fun write(message: String) {
        println("TRACE: $message")
    }
}

We also need to adjust the chain setup.

val traceLogger = TraceLogger()
traceLogger.setNext(infoLogger)

A Few More Real-Life Applications

• Middleware in Web Frameworks: Processing HTTP requests in frameworks like Spring Boot or Ktor.
• Authorization Systems: Sequential permission checks.
• Form Validation: Sequential checks for input validation.
• Payment Processing: Delegating payment methods to appropriate processors.

Advantages and Disadvantages

Advantages

• Flexibility: Easily add or remove handlers in the chain.
• Decoupling: The sender doesn’t know which handler processes the request.
• Open/Closed Principle: New handlers can be added without modifying existing code.

Disadvantages

• No Guarantee of Handling: If no handler processes the request, it may go unhandled.
• Debugging Complexity: Long chains can be hard to trace.

Conclusion

The Chain of Responsibility pattern offers an elegant solution for delegating requests through a sequence of handlers. By decoupling the sender of a request from its receivers, this approach enhances flexibility and improves the maintainability of your code. Each handler focuses on specific tasks and passes unhandled requests to the next handler in the chain.

In this guide, we explored practical examples to illustrate the use of the Chain of Responsibility pattern in Kotlin, showcasing its application in scenarios like leave approval and discount processing. The pattern proves highly adaptable to diverse use cases, allowing for clean and organized request handling.

Incorporating this pattern into your design helps build systems that are easier to extend, maintain, and scale, ensuring they remain robust in the face of changing requirements.

The Chain of Responsibility Pattern is a powerful design pattern that helps streamline the process of handling requests in a system. By allowing multiple handlers to process a request, this pattern ensures that the request is passed through a chain until it’s appropriately dealt with. In this blog, we will explore essential Chain of Responsibility Pattern examples, diving into its structure and providing key insights on how this pattern can be effectively used to create more flexible and maintainable code. Whether you’re new to design patterns or looking to expand your knowledge, this guide will help you understand the full potential of this pattern.

What is the Chain of Responsibility (CoR) Pattern?

The Chain of Responsibility design pattern is a behavioral design pattern that allows passing a request along a chain of handlers, where each handler has a chance to process the request or pass it along to the next handler in the chain. The main goal is to decouple the sender of a request from its receivers, giving multiple objects a chance to handle the request.

Think of a company where a request, such as budget approval, must go through several levels of management. At each level, the manager can either address the request or escalate it to the next level.

Now imagine another situation: an employee submits a leave application. Depending on the duration of leave, it might need approval from different authorities, such as a team leader, department head, or higher management.

These scenarios capture the essence of the Chain of Responsibility design pattern, where a request is passed along a series of handlers, each with the choice to process it or forward it.

Why Use the Chain of Responsibility Pattern?

Before we delve into the structure and implementation of the Chain of Responsibility (CoR) pattern, let’s first understand why it’s important.

Consider a situation where multiple objects are involved in processing a request, and the handling varies depending on the specific conditions. For example, in online shopping platforms like Myntra or Amazon, or food delivery services such as Zomato or Swiggy, a customer might use a discount code or coupon. The system needs to determine if the code is valid or decide which discount should apply based on the circumstances.

This is where the Chain of Responsibility pattern becomes highly useful. Rather than linking the request to a specific handler, it enables the creation of a chain of handlers, each capable of managing the request in its unique way. This makes the system more adaptable, allowing developers to easily add, remove, or modify handlers without affecting the core logic.

Structure of the Chain of Responsibility Pattern

Key Idea

• Decouple the sender and receiver.
• Each handler in the chain determines if it can handle the request.

Handler (Abstract Class or Interface)

Defines the interface for handling requests and the reference to the next handler in the chain.

abstract class Handler {
    protected var nextHandler: Handler? = null
    
    abstract fun handleRequest(request: String)
    
    fun setNextHandler(handler: Handler) {
        nextHandler = handler
    }
}

• This defines an interface for handling requests, usually with a method like handleRequest(). It may also have a reference to the next handler in the chain.
• The handler may choose to process the request or pass it on to the next handler.

ConcreteHandler

Implement the handleRequest() method to either process the request or pass it to the next handler.

class ConcreteHandlerA : Handler() {
    override fun handleRequest(request: String) {
        if (request == "A") {
            println("Handler A processed request: $request")
        } else {
            nextHandler?.handleRequest(request)
        }
    }
}

class ConcreteHandlerB : Handler() {
    override fun handleRequest(request: String) {
        if (request == "B") {
            println("Handler B processed request: $request")
        } else {
            nextHandler?.handleRequest(request)
        }
    }
}

• These are the actual handler classes that implement the handleRequest() method. Each concrete handler will either process the request or pass it to the next handler in the chain.
• If a handler is capable of processing the request, it does so; otherwise, it forwards the request to the next handler in the chain.

Client

Interacts only with the first handler in the chain, unaware of the specific handler processing the request.

fun main() {
    val handlerA = ConcreteHandlerA()
    val handlerB = ConcreteHandlerB()

    handlerA.setNextHandler(handlerB)
    
    // Client sends the request to the first handler
    handlerA.handleRequest("A") // Handler A processes the request
    handlerA.handleRequest("B") // Handler B processes the request
}

• The client sends the request to the first handler in the chain. The client does not need to know which handler will eventually process the request.

Chain of Responsibility Pattern Examples : Real-World Use Cases

Now, let’s roll up our sleeves and dive into real-world use case code.

Handling Employee Request

Let’s revisit our employee leave request scenario, where we need to approve a leave request in a company. The leave request should be processed by different authorities depending on the amount of leave being requested. Here’s the hierarchy:

• Employee: Initiates the leave request by submitting it to their immediate supervisor or system.
• Manager (up to 5 days): Approves short leaves to handle minor requests efficiently.
• Director (up to 15 days): Approves extended leaves, ensuring alignment with organizational policies.
• HR (more than 15 days): Handles long-term leave requests, requiring policy compliance or special considerations.

Using the Chain of Responsibility, we can chain the approval process such that if one handler (e.g., Manager) cannot process the request, it is passed to the next handler (e.g., Director).

Define the Handler Interface

The handler interface is a blueprint for the handlers that will process requests. Each handler can either process the request or pass it along to the next handler in the chain.

// Create the Handler interface
interface LeaveRequestHandler {
    fun handleRequest(request: LeaveRequest)
}

In this case, the handleRequest function takes a LeaveRequest object, which holds the details of the leave request, and processes it.

Define the Request Object

The request object contains all the information related to the request. Here, we’ll create a simple LeaveRequest class.

// Create the LeaveRequest object
data class LeaveRequest(val employeeName: String, val numberOfDays: Int)

Create Concrete Handlers

Now, we’ll implement different concrete handlers for each authority: Manager, Director, and HR. Each handler will check if it can approve the leave request based on the number of days requested.

// Implement the Manager Handler
class Manager(private val nextHandler: LeaveRequestHandler? = null) : LeaveRequestHandler {
    override fun handleRequest(request: LeaveRequest) {
        if (request.numberOfDays <= 5) {
            println("Manager approved ${request.employeeName}'s leave for ${request.numberOfDays} days.")
        } else {
            nextHandler?.handleRequest(request)
        }
    }
}

// Implement the Director Handler
class Director(private val nextHandler: LeaveRequestHandler? = null) : LeaveRequestHandler {
    override fun handleRequest(request: LeaveRequest) {
        if (request.numberOfDays <= 15) {
            println("Director approved ${request.employeeName}'s leave for ${request.numberOfDays} days.")
        } else {
            nextHandler?.handleRequest(request)
        }
    }
}

// Implement the HR Handler
class HR : LeaveRequestHandler {
    override fun handleRequest(request: LeaveRequest) {
        println("HR approved ${request.employeeName}'s leave for ${request.numberOfDays} days.")
    }
}

Each handler checks whether the request can be processed. If it cannot, the request is passed to the next handler in the chain.

Set Up the Chain

Next, we’ll set up the chain of responsibility. We will link the handlers so that each handler knows who to pass the request to if it can’t handle it.

// Setup the chain
fun createLeaveApprovalChain(): LeaveRequestHandler {
    val hr = HR()
    val director = Director(hr)
    val manager = Manager(director)
    
    return manager // The chain starts with the Manager
}

• If the Manager can’t approve the leave (i.e., the request is for more than 5 days), it passes the request to the Director.
• If the Director can’t approve the leave (i.e., the request is for more than 15 days), it passes the request to HR, which will handle it.

Test the Chain of Responsibility

Now, let’s create a LeaveRequest and pass it through the chain.

fun main() {
    val leaveRequest = LeaveRequest("amol pawar", 10)
    
    val approvalChain = createLeaveApprovalChain()
    approvalChain.handleRequest(leaveRequest)
}

// OUTPUT

// Director approved amol pawar's leave for 10 days.

Now, one more familiar use case that many of us have likely worked with in past projects is the Logging System.

Logging System

Let’s implement a logging system where log messages are passed through a chain of loggers. Each logger decides whether to handle the log or pass it along. We’ll include log levels: INFO, DEBUG, and ERROR.

Define a Base Logger Class

First, we’ll create an abstract Logger class. This will act as the base for all specific loggers.

abstract class Logger(private val level: Int) {

    private var nextLogger: Logger? = null

    // Set the next logger in the chain
    fun setNext(logger: Logger): Logger {
        this.nextLogger = logger
        return logger
    }

    // Handle the log request
    fun logMessage(level: Int, message: String) {
        if (this.level == level) {
            write(message)
            return                // To stop further propagation
        }
        nextLogger?.logMessage(level, message)
    }

    // Abstract method for handling the log
    protected abstract fun write(message: String)
}

Here,

• level: Defines the log level this logger will handle.
• nextLogger: Points to the next handler in the chain.
• setNext: Configures the next logger in the chain, enabling chaining.
• logMessage: Checks if the logger should process the message based on its level. If not, it delegates the task to the next logger in the chain.
• return: Why used return here..? The return is used to prevent the log message from being passed to the next logger after it has been processed. It ensures that once a logger handles the message, it won’t be forwarded further, avoiding redundant output.

Create Specific Logger Implementations

Let’s create concrete loggers for INFO, DEBUG, and ERROR levels.

class InfoLogger : Logger(1) {
    override fun write(message: String) {
        println("INFO: $message")
    }
}

class DebugLogger : Logger(2) {
    override fun write(message: String) {
        println("DEBUG: $message")
    }
}

class ErrorLogger : Logger(3) {
    override fun write(message: String) {
        println("ERROR: $message")
    }
}

• Each logger overrides the write method to handle messages at its respective log level.
• For instance, the InfoLogger handles logs with a level of 1, while higher levels (DEBUG or ERROR) are passed down the chain.

Setting Up the Chain

Now, let’s set up a chain of loggers: INFO → DEBUG → ERROR.

fun getLoggerChain(): Logger {
    val errorLogger = ErrorLogger()
    val debugLogger = DebugLogger()
    val infoLogger = InfoLogger()

    infoLogger.setNext(debugLogger).setNext(errorLogger)

    return infoLogger
}

• We instantiate the loggers and chain them together using setNext.
• The chain starts with InfoLogger and ends with ErrorLogger.

Using the Logger Chain

Now, let’s test our chain.

fun main() {
    val loggerChain = getLoggerChain()

    println("Testing Chain of Responsibility:")
    loggerChain.logMessage(1, "This is an info message.")
    loggerChain.logMessage(2, "This is a debug message.")
    loggerChain.logMessage(3, "This is an error message.")
}

Output

Testing Chain of Responsibility:
INFO: This is an info message.
DEBUG: This is a debug message.
ERROR: This is an error message.

Basically, what happens here is,

• A log with level 1 is processed by InfoLogger.
• A log with level 2 is handled by DebugLogger.
• A log with level 3 is processed by ErrorLogger.

If no logger in the chain can handle a request, it simply passes through without being processed.

Extending the Chain

What if we wanted to add more log levels, like TRACE? Easy..! Just implement a TraceLogger and link it to the chain without modifying the existing code.

class TraceLogger : Logger(0) {
    override fun write(message: String) {
        println("TRACE: $message")
    }
}

We also need to adjust the chain setup.

val traceLogger = TraceLogger()
traceLogger.setNext(infoLogger)

Some Other Real-Life Applications

• Middleware in Web Frameworks: Processing HTTP requests in frameworks like Spring Boot or Ktor.
• Authorization Systems: Sequential permission checks.
• Form Validation: Sequential checks for input validation.
• Payment Processing: Delegating payment methods to appropriate processors.

Advantages and Disadvantages

Advantages

• Flexibility: Easily add or remove handlers in the chain.
• Decoupling: The sender doesn’t know which handler processes the request.
• Open/Closed Principle: New handlers can be added without modifying existing code.

Disadvantages

• No Guarantee of Handling: If no handler processes the request, it may go unhandled.
• Debugging Complexity: Long chains can be hard to trace.

Cocnlusion

The Chain of Responsibility Pattern offers a flexible and scalable solution to handling requests, making it an essential tool for developers looking to decouple their system’s components. Through the examples and insights shared, it becomes clear how this pattern can simplify complex workflows and enhance maintainability. By mastering the structure and application of the Chain of Responsibility pattern, you can ensure your systems are more adaptable to future changes, ultimately improving both code quality and overall project efficiency.

The Chain of Responsibility pattern is a behavioral design pattern that allows a request to be passed along a chain of handlers until it is processed. This pattern is particularly powerful in scenarios where multiple objects can process a request, but the handler is not determined until runtime. In this blog, we will be unveiling the powerful structure of the Chain of Responsibility pattern, breaking down its key components and flow. By the end, you’ll have a solid understanding of how this pattern can improve flexibility and scalability in your application design.

What is the Chain of Responsibility (CoR) Pattern?

The Chain of Responsibility design pattern is a behavioral design pattern that allows passing a request along a chain of handlers, where each handler has a chance to process the request or pass it along to the next handler in the chain. The main goal is to decouple the sender of a request from its receivers, giving multiple objects a chance to handle the request.

That means the CoR pattern allows multiple objects to handle a request without the sender needing to know which object handled it. The request is passed along a chain of objects (handlers), where each handler has the opportunity to process it or pass it to the next one.

Think of a company where a request, such as budget approval, must go through several levels of management. At each level, the manager can either address the request or escalate it to the next level.

Now imagine another situation: an employee submits a leave application. Depending on the duration of leave, it might need approval from different authorities, such as a team leader, department head, or higher management.

Why Use the Chain of Responsibility Pattern?

Before we delve into the structure and implementation of the Chain of Responsibility (CoR) pattern, let’s first understand why it’s important.

Consider a situation where multiple objects are involved in processing a request, and the handling varies depending on the specific conditions. For example, in online shopping platforms like Myntra or Amazon, or food delivery services such as Zomato or Swiggy, a customer might use a discount code or coupon. The system needs to determine if the code is valid or decide which discount should apply based on the circumstances.

This is where the Chain of Responsibility pattern becomes highly useful. Rather than linking the request to a specific handler, it enables the creation of a chain of handlers, each capable of managing the request in its unique way. This makes the system more adaptable, allowing developers to easily add, remove, or modify handlers without affecting the core logic.

So, the Chain of Responsibility pattern offers several advantages:

• Decouples the sender and receiver: The sender doesn’t need to know which object in the chain will handle the request.
• Simplifies the code: It eliminates complex conditionals and decision trees by delegating responsibility to handlers in the chain.
• Adds flexibility: New handlers can be seamlessly added to the chain without impacting the existing implementation.

These scenarios capture the essence of the Chain of Responsibility design pattern, where a request is passed along a series of handlers, each with the choice to process it or forward it.

Structure of the Chain of Responsibility Pattern

The Chain of Responsibility pattern consists of:

1. Handler Interface: Declares a method to process requests and optionally set the next handler.
2. Concrete Handlers: Implements the interface and processes the request.
3. Client Code: Creates and configures the chain.

Handler (Abstract Class or Interface)

Defines the interface for handling requests and the reference to the next handler in the chain.

abstract class Handler {
    protected var nextHandler: Handler? = null
    
    abstract fun handleRequest(request: String)
    
    fun setNextHandler(handler: Handler) {
        nextHandler = handler
    }
}

• This defines an interface for handling requests, usually with a method like handleRequest(). It may also have a reference to the next handler in the chain.
• The handler may choose to process the request or pass it on to the next handler.

ConcreteHandler

Implement the handleRequest() method to either process the request or pass it to the next handler.

class ConcreteHandlerA : Handler() {
    override fun handleRequest(request: String) {
        if (request == "A") {
            println("Handler A processed request: $request")
        } else {
            nextHandler?.handleRequest(request)
        }
    }
}

class ConcreteHandlerB : Handler() {
    override fun handleRequest(request: String) {
        if (request == "B") {
            println("Handler B processed request: $request")
        } else {
            nextHandler?.handleRequest(request)
        }
    }
}

• These are the actual handler classes that implement the handleRequest() method. Each concrete handler will either process the request or pass it to the next handler in the chain.
• If a handler is capable of processing the request, it does so; otherwise, it forwards the request to the next handler in the chain.

Client

Interacts only with the first handler in the chain, unaware of the specific handler processing the request.

fun main() {
    val handlerA = ConcreteHandlerA()
    val handlerB = ConcreteHandlerB()

    handlerA.setNextHandler(handlerB)
    
    // Client sends the request to the first handler
    handlerA.handleRequest("A") // Handler A processes the request
    handlerA.handleRequest("B") // Handler B processes the request
}

• The client sends the request to the first handler in the chain. The client does not need to know which handler will eventually process the request.

As we can see, this structure allows requests to pass through multiple handlers in the chain, with each handler having the option to process the request or delegate it.

Advantages and Disadvantages

Advantages

• Flexibility: Easily add or remove handlers in the chain.
• Decoupling: The sender doesn’t know which handler processes the request.
• Open/Closed Principle: New handlers can be added without modifying existing code.

Disadvantages

• No Guarantee of Handling: If no handler processes the request, it may go unhandled.
• Debugging Complexity: Long chains can be hard to trace.

Conclusion

The Chain of Responsibility pattern offers a robust solution for handling requests in a decoupled and flexible way, allowing for easier maintenance and scalability. By understanding the structure and key components of this pattern, you can effectively apply it to scenarios where multiple handlers are required to process requests in a dynamic and streamlined manner. Whether you’re developing complex systems or optimizing existing architectures, this pattern is a valuable tool that can enhance the efficiency and adaptability of your software design.

The Proxy design pattern is a structural pattern that acts as a stand-in or “placeholder” for another object, helping control access to it. By applying this pattern, you add an extra layer that manages an object’s behavior, all without altering the original object. In this article, we’ll explore the basics of the Proxy pattern, dive into real-world examples where it proves useful, and guide you through a Kotlin implementation with step-by-step explanations to make everything clear and approachable.

Proxy Design Pattern

In programming, objects sometimes need additional layers of control—whether it’s for performance optimizations, access restrictions, or simplifying complex operations. The Proxy pattern achieves this by creating a “proxy” class that represents another class. This proxy class controls access to the original class and can be used to introduce additional logic before or after the actual operations.

It’s particularly useful in situations where object creation is resource-intensive, or you want finer control over how and when the object interacts with other parts of the system. In Android, proxies are commonly used for lazy loading, network requests, and logging.

When to Use Proxy Pattern

The Proxy pattern is beneficial when:

1. You want to control access to an object.
2. You need to defer object initialization (lazy initialization).
3. You want to add functionalities, like caching or logging, without modifying the actual object.

Structure of Proxy Pattern

The Proxy Pattern involves three main components:

1. Subject Interface – Defines the common interface that both the RealSubject and Proxy implement.
2. RealSubject – The actual object being represented or accessed indirectly.
3. Proxy – Controls access to the RealSubject.

Types of Proxies

Different types of proxies serve distinct purposes:

• Remote Proxy: Manages resources in remote systems.
• Virtual Proxy: Manages resource-heavy objects and instantiates them only when needed.
• Protection Proxy: Controls access based on permissions.
• Cache Proxy: Caches responses to improve performance.

Real-World Use Cases

The Proxy pattern is widely used in scenarios such as:

• Virtual Proxies: Delaying object initialization (e.g., for memory-heavy objects).
• Protection Proxies: Adding security layers to resources (e.g., restricting access).
• Remote Proxies: Representing objects that are in different locations (e.g., APIs).

Let’s consider a video streaming scenario, similar to popular platforms like Disney+ Hotstar, Netflix, or Amazon Prime. Here, a proxy can be used to control access to video data based on the user’s subscription type. For instance, the proxy could restrict access to premium content for free-tier users, ensuring that only eligible users can stream certain videos. This adds a layer of control, enhancing security and user experience while keeping the main video service logic clean and focused.

Here’s the simple proxy implementation,

First we define the interface

interface VideoService {
    fun streamVideo(videoId: String): String
}

Create the Real Object

The RealVideoService class represents the actual video streaming service. It implements the VideoService interface and streams video.

class RealVideoService : VideoService {
    override fun streamVideo(videoId: String): String {
        // Simulate streaming a large video file
        return "Streaming video content for video ID: $videoId"
    }
}

Create the Proxy Class

The VideoServiceProxy class controls access to the RealVideoService. We’ll implement it so only premium users can access certain videos, adding a layer of security.

class VideoServiceProxy(private val isPremiumUser: Boolean) : VideoService {

    // Real service reference
    private val realVideoService = RealVideoService()

    override fun streamVideo(videoId: String): String {
        return if (isPremiumUser) {
            // Delegate call to real object if the user is premium
            realVideoService.streamVideo(videoId)
        } else {
            // Restrict access for non-premium users
            "Upgrade to premium to stream this video."
        }
    }
}

Testing the Proxy

Now, let’s simulate clients trying to stream a video through the proxy.

fun main() {
    val premiumUserProxy = VideoServiceProxy(isPremiumUser = true)
    val regularUserProxy = VideoServiceProxy(isPremiumUser = false)

    println("Premium User Request:")
    println(premiumUserProxy.streamVideo("premium_video_123"))

    println("Regular User Request:")
    println(regularUserProxy.streamVideo("premium_video_123"))
}

Output

Premium User Request:
Streaming video content for video ID: premium_video_123

Regular User Request:
Upgrade to premium to stream this video.