Design Patterns

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..! 🚀

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.