Amol Pawar

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.

Here,

• Interface (VideoService): The VideoService interface defines the contract for streaming video.
• Real Object (RealVideoService): The RealVideoService implements the VideoService interface, providing the actual video streaming functionality.
• Proxy Class (VideoServiceProxy): The VideoServiceProxy class implements the VideoService interface and controls access to RealVideoService. It checks whether the user is premium and either allows streaming or restricts it.
• Client: The client interacts with VideoServiceProxy, not with RealVideoService. The proxy makes the access control transparent for the client.

Benefits and Limitations

Benefits

• Controlled Access: Allows us to restrict access based on custom logic.
• Lazy Initialization: We can load resources only when required.
• Security: Additional security checks can be implemented.

Limitations

• Complexity: It can add unnecessary complexity if access control is not required.
• Performance: May slightly impact performance because of the extra layer.

Conclusion

The Proxy design pattern is a powerful tool for managing access, adding control, and optimizing performance in your applications. By introducing a proxy, you can enforce access restrictions, add caching, or defer resource-intensive operations, all without changing the core functionality of the real object. In our video streaming example, the proxy ensures only authorized users can access premium content, demonstrating how this pattern can provide both flexibility and security. Mastering the Proxy pattern in Kotlin can help you build more robust and scalable applications, making it a valuable addition to your design pattern toolkit.

Ever notice how every app we use—from Amazon to our banking apps—makes everything seem so effortless? What we see on the surface is just the tip of the iceberg. Beneath that sleek interface lies a mountain of complex code working tirelessly to ensure everything runs smoothly. This is where the Facade Design Pattern shines, providing a way to hide all those intricate details and offering us a straightforward way to interact with complex systems.

So, what exactly is a facade? Think of it as a smooth layer that conceals the complicated stuff, allowing us to focus on what truly matters. In coding, this pattern lets us wrap multiple components or classes into one easy-to-use interface, making our interactions clean and simple. And if you’re using Kotlin, implementing this pattern is a breeze—Kotlin’s modern syntax and interfaces make creating facades feel effortless.

You might be wondering, “Isn’t this just like data hiding in OOP?” Not quite! Facades are more about simplifying access to complex systems rather than merely keeping details private. So, let’s dive in, explore what makes the Facade Pattern so powerful, look at real-life examples, and see the ups and downs of using it in Kotlin. Let’s get started!

Facade Design Pattern

The Facade pattern is part of the structural design patterns in the well-known Gang of Four (GoF) design patterns. This pattern provides a simplified interface to a complex subsystem, which may involve multiple classes and interactions. The primary goal of the Facade pattern is to reduce the complexity by creating a single entry point that manages complex logic behind the scenes, allowing the client (user of the code) to interact with a simplified interface.

In simple words, instead of directly interacting with multiple classes, methods, or modules within a complex subsystem, a client can work with a single Facade class that handles the complexities.

Imagine you’re trying to use a complex appliance with lots of buttons and settings. Instead of figuring out how to navigate all those features, you just have a single, easy-to-use control panel that manages everything behind the scenes. That’s exactly what the Facade pattern does.

It creates a straightforward interface that acts as a single entry point to a complex subsystem. This way, you don’t have to deal with multiple classes or methods directly; you can just interact with the Facade class, which takes care of all the complexity for you. It’s all about making things easier and less overwhelming!

I always believe that to truly use or understand any design pattern, it’s essential to grasp its structure first. Once we have a solid understanding of how it works, we can apply it to our everyday coding. So, let’s take a look at the structure of facade pattern first, and then we can dive into the coding part together.

Structure of the Facade Design Pattern

In the Facade Pattern, we have:

1. Subsystem classes that handle specific, granular tasks.
2. A Facade class that provides a simplified interface to these subsystems, delegating requests to the appropriate classes.

Let’s see how this looks in Kotlin.

Simple Scenario

Think about our office coffee maker for a second. When we want to brew our favorite blend, we often have to click multiple buttons on the control panel. Let’s see how we can make coffee with a single click using the Facade pattern in our code.

We’ll create a CoffeeMaker class that includes complex subsystems: a Grinder, a Boiler, and a CoffeeMachine. The CoffeeMakerFacade will provide a simple interface for the user to make coffee without dealing with the underlying complexity.

// Subsystem 1: Grinder
class Grinder {
    fun grindBeans() {
        println("Grinding coffee beans...")
    }
}

// Subsystem 2: Boiler
class Boiler {
    fun heatWater() {
        println("Heating water...")
    }
}

// Subsystem 3: CoffeeMachine
class CoffeeMachine {
    fun brewCoffee() {
        println("Brewing coffee...")
    }
}

// Facade: CoffeeMakerFacade
class CoffeeMakerFacade(
    private val grinder: Grinder,
    private val boiler: Boiler,
    private val coffeeMachine: CoffeeMachine
) {
    fun makeCoffee() {
        println("Starting the coffee-making process...")
        grinder.grindBeans()
        boiler.heatWater()
        coffeeMachine.brewCoffee()
        println("Coffee is ready!")
    }
}

// Client code
fun main() {
    // Creating subsystem objects
    val grinder = Grinder()
    val boiler = Boiler()
    val coffeeMachine = CoffeeMachine()

    // Creating the Facade
    val coffeeMaker = CoffeeMakerFacade(grinder, boiler, coffeeMachine)

    // Using the Facade to make coffee
    coffeeMaker.makeCoffee()
}



// Output 

Starting the coffee-making process...
Grinding coffee beans...
Heating water...
Brewing coffee...
Coffee is ready!

Here,

Subsystems

• Grinder: Handles the coffee bean grinding.
• Boiler: Manages the heating of water.
• CoffeeMachine: Responsible for brewing the coffee.

Facade

• CoffeeMakerFacade: Simplifies the coffee-making process by providing a single method makeCoffee(), which internally calls the necessary methods from the subsystems in the correct order.

Client Code

• The main() function creates instances of the subsystems and the facade. It then calls makeCoffee(), demonstrating how the facade abstracts the complexity of the underlying systems.

This is just a simple example to help us understand how the Facade pattern works. Next, we’ll explore another real-world scenario that’s more complex, but we’ll keep it simple.

Facade Pattern in Travel Booking System

Let’s say we want to provide a simple way for users to book their entire travel package in one go without worrying about booking each service (flight, hotel, taxi) individually. 

Here’s how the Facade pattern can help!

We’ll create a TravelFacade to handle flight, hotel, and taxi bookings, making the experience seamless. Each booking service—flight, hotel, and taxi—will have its own class with separate logic, while TravelFacade provides a unified interface to book the entire package.

Before we write the facade interface, let’s start by defining each booking service.

//Note: It's better to define each service in a separate file.

// FlightBooking.kt
class FlightBooking {
    fun bookFlight(from: String, to: String): String {
        // Simulate flight booking logic
        return "Flight booked from $from to $to"
    }
}

// HotelBooking.kt
class HotelBooking {
    fun bookHotel(location: String, nights: Int): String {
        // Simulate hotel booking logic
        return "$nights-night stay booked in $location"
    }
}

// TaxiBooking.kt
class TaxiBooking {
    fun bookTaxi(pickupLocation: String, destination: String): String {
        // Simulate taxi booking logic
        return "Taxi booked from $pickupLocation to $destination"
    }
}

Now, the TravelFacade class will act as a single interface that the client interacts with to book their entire travel package.

// TravelFacade.kt
class TravelFacade {
    private val flightBooking = FlightBooking()
    private val hotelBooking = HotelBooking()
    private val taxiBooking = TaxiBooking()

    fun bookFullPackage(from: String, to: String, hotelLocation: String, nights: Int): List<String> {
        val flightConfirmation = flightBooking.bookFlight(from, to)
        val hotelConfirmation = hotelBooking.bookHotel(hotelLocation, nights)
        val taxiConfirmation = taxiBooking.bookTaxi("Airport", hotelLocation)

        return listOf(flightConfirmation, hotelConfirmation, taxiConfirmation)
    }
}

And now, the client can simply use the TravelFacade without worrying about managing individual bookings for flights, hotels, and taxis

// Main.kt
fun main() {
    val travelFacade = TravelFacade()
    
    val travelPackage = travelFacade.bookFullPackage(
        from = "New York",
        to = "Paris",
        hotelLocation = "Paris City Center",
        nights = 5
    )

    // Display the booking confirmations
    travelPackage.forEach { println(it) }
}

Output

Flight booked from Pune to Andaman and Nicobar Islands
5-night stay booked in Welcomhotel By ITC Hotels, Marine Hill, Port Blair
Taxi booked from Airport to Welcomhotel By ITC Hotels, Marine Hill, Port Blair

Here,

• Individual services (FlightBooking, HotelBooking, TaxiBooking) have their own booking logic.
• TravelFacade abstracts the booking process, allowing the client to book a complete package with one call to bookFullPackage().
• The client doesn’t need to understand or interact with each subsystem directly.

Let’s look at another use case in Android. Facade can be applied across different architectures, but I’ll give a more general view so anyone can easily relate and apply it in their code.

Network Communication Facade in Android

Creating a Network Communication Facade in Android with Kotlin helps us streamline and simplify how we interact with different network APIs and methods. This pattern lets us hide the complex details of various network operations, providing the app with a single, easy-to-use interface for making network requests. It’s especially handy when you want to work with multiple networking libraries or APIs in a consistent way.

Here’s a look at how a Network Communication Facade could work in Kotlin

First, let’s start by creating a NetworkFacade interface.

This interface defines the available methods for network operations (we’ll keep it simple with common methods like GET and POST). Any network client can implement this interface to handle requests.

interface NetworkFacade {
    suspend fun get(url: String): Result<String>
    suspend fun post(url: String, body: Map<String, Any>): Result<String>
    // Additional HTTP methods can be added if needed
}

Now, let’s implement this interface with a network client, such as Retrofit or OkHttp. Here, I’ll use OkHttp as an example.

import okhttp3.OkHttpClient
import okhttp3.Request
import okhttp3.RequestBody.Companion.toRequestBody
import okhttp3.MediaType.Companion.toMediaType
import okhttp3.Response
import org.json.JSONObject
import kotlin.Result

class OkHttpNetworkFacade : NetworkFacade {

    private val client = OkHttpClient()

    override suspend fun get(url: String): Result<String> {
        val request = Request.Builder()
            .url(url)
            .get()
            .build()

        return client.newCall(request).execute().use { response ->
            if (response.isSuccessful) {
                Result.success(response.body?.string() ?: "")
            } else {
                Result.failure(Exception("GET request failed with code: ${response.code}"))
            }
        }
    }

    override suspend fun post(url: String, body: Map<String, Any>): Result<String> {
        val json = JSONObject(body).toString()
        val requestBody = json.toRequestBody("application/json; charset=utf-8".toMediaType())

        val request = Request.Builder()
            .url(url)
            .post(requestBody)
            .build()

        return client.newCall(request).execute().use { response ->
            if (response.isSuccessful) {
                Result.success(response.body?.string() ?: "")
            } else {
                Result.failure(Exception("POST request failed with code: ${response.code}"))
            }
        }
    }
}

If we need to switch to Retrofit for other services, we can also implement the same interface for Retrofit.

import retrofit2.Retrofit
import retrofit2.converter.gson.GsonConverterFactory
import retrofit2.http.Body
import retrofit2.http.GET
import retrofit2.http.POST
import retrofit2.http.Url

interface RetrofitApiService {
    @GET
    suspend fun get(@Url url: String): String

    @POST
    suspend fun post(@Url url: String, @Body body: Map<String, Any>): String
}

class RetrofitNetworkFacade : NetworkFacade {
    
    private val api: RetrofitApiService = Retrofit.Builder()
        .baseUrl("https://use-your-base-url-here.com/")
        .addConverterFactory(GsonConverterFactory.create())
        .build()
        .create(RetrofitApiService::class.java)

    override suspend fun get(url: String): Result<String> {
        return try {
            val response = api.get(url)
            Result.success(response)
        } catch (e: Exception) {
            Result.failure(e)
        }
    }

    override suspend fun post(url: String, body: Map<String, Any>): Result<String> {
        return try {
            val response = api.post(url, body)
            Result.success(response)
        } catch (e: Exception) {
            Result.failure(e)
        }
    }
}

Now, we can use the NetworkFacade in the application without worrying about which implementation is in use. This makes it easy to switch between different networking libraries if needed.

class NetworkRepository(private val networkFacade: NetworkFacade) {

    suspend fun fetchData(url: String): Result<String> {
        return networkFacade.get(url)
    }

    suspend fun sendData(url: String, data: Map<String, Any>): Result<String> {
        return networkFacade.post(url, data)
    }
}

To enable flexible configuration, we can use dependency injection (DI) to inject the desired facade implementation—either OkHttpNetworkFacade or RetrofitNetworkFacade—when creating the NetworkRepository.

// Use OkHttpNetworkFacade
val networkRepository = NetworkRepository(OkHttpNetworkFacade())

// Or use RetrofitNetworkFacade
val networkRepository = NetworkRepository(RetrofitNetworkFacade())

Here,

NetworkFacade: This interface defines our network operations. Each client, whether it’s OkHttp or Retrofit, can implement this interface, offering different underlying functionalities while maintaining a consistent API for the application.

Result: We use a Result type to manage successful and failed network calls, which reduces the need for multiple try-catch blocks.

NetworkRepository: The repository interacts with the network clients through the facade. It doesn’t need to know which client is in use, providing flexibility and simplifying testing.

This structure allows us to add more network clients (like Ktor) in the future or easily swap out existing ones without changing the application logic that relies on network requests.

Benefits of the Facade Pattern

The Facade pattern offers several advantages, especially when dealing with complex systems. Here are a few key benefits:

• Simplifies Usage: It hides the complexity of subsystems and provides a single point of access, making it easier for clients to interact with the system.
• Improves Readability and Maintainability: With a unified interface, understanding the code flow becomes much simpler, which helps in maintaining the code over time.
• Reduces Dependencies: It decouples clients from subsystems, allowing for changes in the underlying system without impacting the client code.
• Increases Flexibility: Changes can be made within the subsystems without affecting the clients using the Facade, providing greater adaptability to future requirements.

When to Use the Facade Pattern

• To Simplify Interactions: Use the Facade pattern when you need to simplify interactions with complex systems or subsystems.
• To Hide Complexity: It’s ideal for hiding complexity from the client, making the system easier to use.
• To Improve Code Readability: The Facade pattern helps enhance code readability by providing a clean, easy-to-understand interface.
• To Maintain a Single Point of Entry: This pattern allows for a single point of entry to different parts of the codebase, which can help manage dependencies effectively.

Disadvantages of the Facade Pattern

While the Facade pattern offers many advantages, it’s essential to consider its drawbacks:

• Potential Over-Simplification: By hiding the underlying complexity, the facade can limit access to the detailed functionality of the subsystem. If users need to interact with specific features not exposed through the facade, they might find it restrictive. For instance, consider a multimedia library with a facade for playing audio and video. If this facade doesn’t allow for adjustments to audio settings like bass or treble, users requiring those tweaks will have to dig into the subsystem, undermining the facade’s purpose.
• Increased Complexity in the Facade: If the facade attempts to manage too many subsystem methods or functionalities, it can become complex itself. This contradicts the goal of simplicity and may require more maintenance. Imagine a facade for a comprehensive payment processing system that tries to include methods for credit card payments, digital wallets, and subscription management. If the facade becomes too feature-rich, it can turn into a large, unwieldy class, making it hard to understand or modify.
• Encapsulation Leakage: The facade pattern can lead to situations where clients become aware of too many details about the subsystems, breaking encapsulation. This can complicate future changes to the subsystem, as clients might depend on specific implementations. For example, if a facade exposes the internal state of a subsystem (like the current status of a printer), clients might start using that state in their logic. If the internal implementation changes (like adopting a new status management system), it could break clients relying on the old state structure.
• Not Always Necessary: For simpler systems, implementing a facade can add unnecessary layers. If the subsystem is already easy to use or doesn’t consist of many components, the facade may be redundant. For example, if you have a simple logging system with a few straightforward methods (like logInfo and logError), creating a facade to wrap these methods might be overkill. In such cases, direct access to the logging methods may be clearer and easier for developers.

Conclusion

The Facade Pattern is a great choice when you want to simplify complex interactions between multiple classes or subsystems. By creating a single entry point, you can make your code much easier to use and understand. With Kotlin’s class structure and concise syntax, implementing this pattern feels smooth and straightforward.

When used thoughtfully, the Facade Pattern can greatly improve code readability, maintainability, and overall usability—especially in complex projects like multimedia systems, payment gateways, or extensive frameworks. Just remember to balance its benefits with potential drawbacks to ensure it aligns with your design goals.

Happy coding! Enjoy creating clean and intuitive interfaces with the Facade Pattern!

Have you ever stopped to marvel at how breathtaking mobile games have become? Think about the background graphics in popular games like PUBG or Pokémon GO. (Honest confession: I haven’t played these myself, but back in my college days, my friends and I used to have epic Counter-Strike and I.G.I. 2 sessions—and, funny enough, the same group now plays PUBG—except me!) Anyway, the real question is: have you noticed just how detailed the game worlds are? You’ve got lush grass fields, towering trees, cozy houses, and fluffy clouds—so many objects that make these games feel alive. But here’s the kicker: how do they manage all that without your phone overheating or the game lagging as the action intensifies?

It turns out that one of the sneaky culprits behind game lag is the sheer number of objects being created over and over, all of which take up precious memory. That’s where the Flyweight Design Pattern swoops in like a hero.

Picture this: you’re playing a game with hundreds of trees, houses, and patches of grass. Now, instead of creating a brand-new tree or patch of grass every time, wouldn’t it make sense to reuse these elements when possible? After all, many of these objects share the same traits—like the green color of grass or the texture of tree leaves. The Flyweight pattern allows the game to do just that: reuse common properties across objects to save memory and keep performance snappy.

In this blog, we’re going to break down exactly how the Flyweight Design Pattern works, why it’s such a game-changer for handling large numbers of similar objects, and how you can use it to optimize your own projects. Let’s dive in and find out how it all works!

What is the Flyweight Pattern?

The Flyweight Pattern is a structural design pattern that reduces memory consumption by sharing as much data as possible with similar objects. Instead of storing the same data repeatedly across multiple instances, the Flyweight pattern stores shared data in a common object and only uses unique data in individual objects. This concept is particularly useful when creating a large number of similar objects.

The core idea behind this pattern is to:

1. Identify and separate intrinsic and extrinsic data.

  Intrinsic data is shared across all objects and remains constant.

  Extrinsic data is unique to each object instance.

2. Store intrinsic data in a shared flyweight object, and pass extrinsic data at runtime.

Let’s break it down with our game example. Imagine a field of grass where each blade has a common characteristic: color. All the grass blades are green, which remains constant across the entire field. This is the intrinsic data — something that doesn’t change, like the color.

Now, think about the differences between the blades of grass. Some may vary in height or shape, like a blade being wider in the middle or taller than another. Additionally, the exact position of each blade in the field differs. These varying factors, such as height and position, are the extrinsic data.

Without using the Flyweight pattern, you would store both the common and unique data for each blade of grass in separate objects, which quickly leads to redundancy and memory bloat. However, with the Flyweight pattern, we extract the common data (the color) and share it across all grass blades using one object. The varying data (height, shape, and position) is stored separately for each blade, reducing memory usage significantly.

In short, the Flyweight pattern helps optimize your game by sharing common attributes while keeping only the unique properties in separate objects. This is especially useful when working with a large number of similar objects like blades of grass in a game.

Structure of Flyweight Design Pattern

Before we jump into the code, let’s break down the structure of the Flyweight Design Pattern to understand how it works:

Flyweight

• Defines an interface that allows flyweight objects to receive and act on external (extrinsic) state.

ConcreteFlyweight

• Implements the Flyweight interface and stores intrinsic state (internal, unchanging data).
• Must be shareable across different contexts.

UnsharedConcreteFlyweight

• While the Flyweight pattern focuses on sharing information, there can be cases where instances of concrete flyweight classes are not shared. These objects may hold their own state.

FlyweightFactory

• Creates and manages flyweight objects.
• Ensures that flyweight objects are properly shared to avoid duplication.

Client

• Holds references to flyweight objects.
• Computes or stores the external (extrinsic) state that the flyweights use.

Basically, the Flyweight pattern works by dividing the object state into two categories:

1. Intrinsic State: Data that can be shared across multiple objects. It is stored in a shared, immutable object.
2. Extrinsic State: Data that is unique to each object instance and is passed to the object when it is used.

Using a Flyweight Factory, objects that share the same intrinsic state are created once and reused multiple times. This approach leads to significant memory savings.

Real World Examples

Grass Field Example

Let’s first implement the Flyweight pattern with a grass field example by creating a Flyweight interface, defining concrete Flyweight classes, building a factory to manage them, and demonstrating their usage with a client.

Define the Flyweight Interface

This interface will declare the method that the flyweight objects will implement.

interface GrassBlade {
    fun display(extrinsicState: GrassBladeState)
}

Create ConcreteFlyweight Class

This class represents the shared intrinsic state (color) of the grass blades.

class ConcreteGrassBlade(private val color: String) : GrassBlade {
    override fun display(extrinsicState: GrassBladeState) {
        println("Grass Blade Color: $color, Height: ${extrinsicState.height}, Position: ${extrinsicState.position}")
    }
}

Create UnsharedConcreteFlyweight Class (if necessary)

If you need blades that may have unique characteristics, you can have this class. For simplicity, we won’t implement any specific logic here.

class UnsharedConcreteGrassBlade : GrassBlade {
    // Implementation for unshared concrete flyweight if needed
    override fun display(extrinsicState: GrassBladeState) {
        // Not shared, just a placeholder
    }
}

Create the FlyweightFactory

This factory class will manage the creation and sharing of grass blade objects.

class GrassBladeFactory {
    private val grassBlades = mutableMapOf<String, GrassBlade>()

    fun getGrassBlade(color: String): GrassBlade {
        return grassBlades.computeIfAbsent(color) { ConcreteGrassBlade(color) }
    }
}

Define the Extrinsic State

This class holds the varying data for each grass blade.

data class GrassBladeState(val height: Int, val position: String)

Implement the Client Code

Here, we will create instances of grass blades and display their properties using the Flyweight pattern.

fun main() {
    val grassBladeFactory = GrassBladeFactory()

    // Creating some grass blades with shared intrinsic state (color) and varying extrinsic state
    val grassBlades = listOf(
        Pair(grassBladeFactory.getGrassBlade("Green"), GrassBladeState(5, "A1")),
        Pair(grassBladeFactory.getGrassBlade("Green"), GrassBladeState(7, "A2")),
        Pair(grassBladeFactory.getGrassBlade("Green"), GrassBladeState(6, "B1")),
        Pair(grassBladeFactory.getGrassBlade("Green"), GrassBladeState(4, "B2")),
        Pair(grassBladeFactory.getGrassBlade("Green"), GrassBladeState(5, "C1")),
        Pair(grassBladeFactory.getGrassBlade("Green"), GrassBladeState(5, "C2"))
    )

    // Displaying the grass blades
    for ((grassBlade, state) in grassBlades) {
        grassBlade.display(state)
    }
}

Output

Grass Blade Color: Green, Height: 5, Position: A1
Grass Blade Color: Green, Height: 7, Position: A2
Grass Blade Color: Green, Height: 6, Position: B1
Grass Blade Color: Green, Height: 4, Position: B2
Grass Blade Color: Green, Height: 5, Position: C1
Grass Blade Color: Green, Height: 5, Position: C2

Here,

• GrassBlade Interface: This defines a method display that takes an extrinsicState.
• ConcreteGrassBlade Class: Implements the Flyweight interface and stores the intrinsic state (color).
• GrassBladeFactory: Manages the creation and sharing of ConcreteGrassBlade instances based on color.
• GrassBladeState Class: Holds the extrinsic state for each grass blade, such as height and position.
• Main Function: This simulates the game, creates multiple grass blades, and demonstrates how shared data and unique data are handled efficiently.

Forest Example

Let’s build the forest now. Here, we’ll render a forest with grass, trees, and flowers, reusing objects to minimize memory usage and improve performance by applying the Flyweight pattern.

In this example, the ForestObject will represent a shared object (like grass, trees, and flowers), and the Forest class will be responsible for managing and rendering these objects with variations in their positions and other properties.

// Step 1: Flyweight Interface
interface ForestObject {
    fun render(x: Int, y: Int) // Render object at given coordinates
}

// Step 2: Concrete Flyweight Classes (Grass, Tree, Flower)
class Grass : ForestObject {
    private val color = "Green" // Shared property

    override fun render(x: Int, y: Int) {
        println("Rendering Grass at position ($x, $y) with color $color")
    }
}

class Tree : ForestObject {
    private val type = "Oak" // Shared property

    override fun render(x: Int, y: Int) {
        println("Rendering Tree of type $type at position ($x, $y)")
    }
}

class Flower : ForestObject {
    private val color = "Yellow" // Shared property

    override fun render(x: Int, y: Int) {
        println("Rendering Flower at position ($x, $y) with color $color")
    }
}

// Step 3: Flyweight Factory (Manages the creation and reuse of objects)
class ForestObjectFactory {
    private val objects = mutableMapOf<String, ForestObject>()

    // Returns an existing object or creates a new one if it doesn't exist
    fun getObject(type: String): ForestObject {
        return objects.getOrPut(type) {
            when (type) {
                "Grass" -> Grass()
                "Tree" -> Tree()
                "Flower" -> Flower()
                else -> throw IllegalArgumentException("Unknown forest object type")
            }
        }
    }
}

// Step 4: Forest Class (Client code to manage and render the forest)
class Forest(private val factory: ForestObjectFactory) {
    private val objectsInForest = mutableListOf<Pair<ForestObject, Pair<Int, Int>>>()

    // Adds a new object with specified type and coordinates
    fun plantObject(type: String, x: Int, y: Int) {
        val forestObject = factory.getObject(type)
        objectsInForest.add(Pair(forestObject, Pair(x, y)))
    }

    // Renders the entire forest
    fun renderForest() {
        for ((obj, position) in objectsInForest) {
            obj.render(position.first, position.second)
        }
    }
}

// Step 5: Testing the Flyweight Pattern
fun main() {
    val factory = ForestObjectFactory()
    val forest = Forest(factory)

    // Planting various objects in the forest (reusing the same objects)
    forest.plantObject("Grass", 10, 20)
    forest.plantObject("Grass", 15, 25)
    forest.plantObject("Tree", 30, 40)
    forest.plantObject("Tree", 35, 45)
    forest.plantObject("Flower", 50, 60)
    forest.plantObject("Flower", 55, 65)

    // Rendering the forest
    forest.renderForest()
}

Here,

Flyweight Interface (ForestObject): This interface defines the method render, which will be used to render objects in the forest.

Concrete Flyweights (Grass, Tree, Flower): These classes implement the ForestObject interface and have shared properties like color and type that are common across multiple instances.

Flyweight Factory (ForestObjectFactory): This class manages the creation and reuse of objects. It ensures that if an object of the same type already exists, it will return the existing object rather than creating a new one.

Client Class (Forest): This class is responsible for planting objects in the forest and rendering them. It uses the factory to obtain objects and stores their positions.

Main Function: In the main function, we plant several objects in the forest, but thanks to the Flyweight Design Pattern, we reuse existing objects to save memory.

Output

Rendering Grass at position (10, 20) with color Green
Rendering Grass at position (15, 25) with color Green
Rendering Tree of type Oak at position (30, 40)
Rendering Tree of type Oak at position (35, 45)
Rendering Flower at position (50, 60) with color Yellow
Rendering Flower at position (55, 65) with color Yellow

Basically, even though we planted multiple grass, tree, and flower objects, the game only created one object per type, thanks to the factory. These objects are reused, with only their positions varying. This approach saves memory and improves performance, especially when there are thousands of similar objects in the game world.

Few more Usecases 

1. Text Rendering Systems: Letters that share the same font, size, and style can be stored as flyweights, while the position of each character in the document is extrinsic.
2. Icons in Operating Systems: Many icons in file browsers share the same image but differ in position or name.
3. Web Browsers: Rendering engines often use flyweights to manage CSS style rules, ensuring that the same styles aren’t recalculated multiple times.

Advantages of the Flyweight Pattern

• Memory Efficient: Reduces the number of objects by sharing common data, thus saving memory.
• Improves Performance: With fewer objects to manage, the program can run faster.
• Scalability: Useful in applications with many similar objects (e.g., games, graphical applications).

Drawbacks of the Flyweight Pattern

• Increased Complexity: The pattern introduces more complexity as you need to manage both intrinsic and extrinsic state separately.
• Less Flexibility: Changes to the intrinsic state can affect all instances of the flyweight, which might not be desired in all situations.
• Thread-Safety Issues: Careful management of shared state is required in a multi-threaded environment.

When to Use Flyweight Pattern

1. When an application has many similar objects: If creating each object individually would use too much memory, like in games with numerous characters or environments.
2. When object creation is expensive: Reusing objects can prevent the overhead of frequently creating new objects.
3. When intrinsic and extrinsic states can be separated: The pattern is effective when most object properties are shareable.

Conclusion

The Flyweight design pattern is a powerful tool when you need to optimize memory usage by sharing objects with similar properties. In this post, we explored how the Flyweight pattern works, saw a real-world analogy, and implemented it in Kotlin using grass field and forest examples in a game.

While the Flyweight pattern can be a great way to reduce memory usage, it’s important to carefully analyze whether it’s necessary in your specific application. For simple applications, this pattern might introduce unnecessary complexity. However, when dealing with a large number of objects with similar characteristics, Flyweight is a great choice.

By understanding the intrinsic and extrinsic state separation, you can effectively implement the Flyweight pattern in Kotlin to build more efficient applications.

The Decorator Design Pattern is a powerful structural design pattern that lets you enhance the behavior of an object on the fly, without touching the code of other objects from the same class. It’s like giving your object a superpower without changing its DNA! This approach offers a smarter alternative to subclassing, allowing you to extend functionality in a flexible and dynamic way.

In this blog, we’ll take a deep dive into the Decorator Design Pattern in Kotlin, uncovering its use cases and walking through practical examples. We’ll start with the basic concept and then dive into code examples to make everything crystal clear. Let’s get started!

What is the Decorator Design Pattern?

The Decorator Pattern allows you to dynamically add behavior to an object without modifying its original structure. It works by wrapping an object with another object that provides additional functionality. This pattern is highly effective when extending the behavior of classes, avoiding the complexity of subclassing. 

Think of this pattern as an alternative to subclassing. Instead of creating a large hierarchy of subclasses to add functionality, we create decorator classes that add functionality by wrapping the base object.

Imagine you have a simple object, like a plain cake. If you want to add chocolate or sprinkles to the cake, you don’t have to create new cakes like ChocolateCake or SprinkleCake. Instead, you wrap the plain cake with decorators like ChocolateDecorator or SprinkleDecorator, adding the extra features.

Before diving into the code, let’s first look at the basic structure of the Decorator design pattern. This will give us better clarity as we move forward and tackle more problems with the code.

Basic Components of the Decorator Design Pattern

• Component: The interface or abstract class defining the structure for objects that can have responsibilities added to them dynamically.
• Concrete Component: The class that is being decorated.
• Decorator: Abstract class or interface that wraps the component and provides additional functionality.
• Concrete Decorator: The specific implementation of the decorator class that adds new behaviors.

I know many of us might not see the connection, so let’s explore how this works together.

Let’s use our cake example,

1. Component (Base Interface or Abstract Class): This is the original object you want to add features to. In our case, it’s a “Cake.”
2. ConcreteComponent: This is the base class that implements the component. This is the plain cake.
3. Decorator (Abstract Class or Interface): This class is the wrapper that contains a reference to the component and can add new behavior.
4. ConcreteDecorator: This is a specific decorator that adds new behavior, like adding chocolate or sprinkles to the cake.

Now, let’s demonstrate this in Kotlin using a simple code snippet.

Step 1: Define the Component Interface

The component defines the base functionality. In our case, we will call it Cake.

// Component
interface Cake {
    fun bake(): String
}

Step 2: Create a Concrete Component (The Plain Cake)

This is the “base” version of the object, which we can decorate later. It has the basic functionality.

// Concrete Component
class PlainCake : Cake {
    override fun bake(): String {
        return "Plain Cake"
    }
}

Step 3: Create the Decorator Class

The decorator class implements the Cake interface and holds a reference to a Cake object (the one being decorated).

// Decorator
abstract class CakeDecorator(private val cake: Cake) : Cake {
    override fun bake(): String {
        return cake.bake() // Delegating the call to the wrapped object
    }
}

Step 4: Create Concrete Decorators (Add Chocolate and Sprinkles)

These are specific decorators that add new behavior. For example, adding chocolate or sprinkles to the cake.

// Concrete Decorator 1: Adding Chocolate
class ChocolateDecorator(cake: Cake) : CakeDecorator(cake) {
    override fun bake(): String {
        return super.bake() + " with Chocolate"
    }
}

// Concrete Decorator 2: Adding Sprinkles
class SprinkleDecorator(cake: Cake) : CakeDecorator(cake) {
    override fun bake(): String {
        return super.bake() + " with Sprinkles"
    }
}

Step 5: Use the Decorators

Now you can take a plain cake and add different decorators (chocolate and sprinkles) to it dynamically.

fun main() {
    // Create a plain cake
    val plainCake = PlainCake()

    // Decorate the plain cake with chocolate
    val chocolateCake = ChocolateDecorator(plainCake)
    println(chocolateCake.bake()) // Output: Plain Cake with Chocolate

    // Further decorate the cake with sprinkles
    val sprinkleChocolateCake = SprinkleDecorator(chocolateCake)
    println(sprinkleChocolateCake.bake()) // Output: Plain Cake with Chocolate with Sprinkles
}

Here, PlainCake is our base object, while ChocolateDecorator and SprinkleDecorator are the wrappers that add delightful flavors without altering the original PlainCake class. You can mix and match these decorators any way you like, dynamically enhancing the cake without changing its original essence.

But wait, here’s a thought! 

You might wonder: since we’re using both inheritance and composition here, why not rely solely on inheritance? Why do we need the help of composition?

And here’s another interesting point: have you noticed how we can avoid the hassle of creating countless subclasses for every combination of behaviors, like ChocolateCake, SprinkleCake, and ChocolateSprinkleCake? Instead, we can simply ‘decorate’ an object with as many behaviors as we want, dynamically, at runtime!

Alright, let’s play a little guessing game… 🤔 Ah, yes! No — wait 😕, it’s actually a no! Now that we’ve had our fun, let’s dive deeper into the problem the Decorator Pattern solves: how it helps us avoid subclass explosion while still offering dynamic behavior at runtime.

I’ll walk you through a real-life scenario to illustrate this before we jump into the code. Let’s break it down into two key points:

1. Inheritance vs. Composition in the Decorator Pattern
2. How this combination avoids subclass explosion while enabling dynamic behavior.

Inheritance vs. Composition in the Decorator Pattern

In the Decorator Pattern, we indeed use both inheritance and composition together. Here’s how:

• Inheritance: Decorators and the base class share a common interface. This is the type system‘s way to ensure that both the decorated object and the original object can be used in the same way (i.e., they both implement the same methods). This is why we inherit from a common interface or abstract class.
• Composition: Instead of adding behavior via inheritance (which creates subclass explosion), we use composition to wrap objects. Each decorator contains an instance of the object it’s decorating. This wrapping allows us to combine behaviors in different ways at runtime.

By using composition (wrapping objects) instead of inheritance (creating subclasses for every combination), the Decorator Pattern allows us to avoid the explosion of subclasses.

Let’s compare this with inheritance-only and then with the Decorator Pattern.

How the Decorator Pattern Avoids Subclass Explosion

Subclass Explosion Problem (Inheritance-Only Approach)

Imagine we have a simple notification system where we want to add sound, vibration, and banner features to notifications. Using inheritance alone, we might end up with:

// Base notification
open class Notification {
    open fun send() = "Sending Notification"
}

// Subclass 1: Add Sound
class SoundNotification : Notification() {
    override fun send() = super.send() + " with Sound"
}

// Subclass 2: Add Vibration
class VibrationNotification : Notification() {
    override fun send() = super.send() + " with Vibration"
}

// Subclass 3: Add Banner
class BannerNotification : Notification() {
    override fun send() = super.send() + " with Banner"
}

// Now we need to combine all features
class SoundVibrationNotification : Notification() {
    override fun send() = super.send() + " with Sound and Vibration"
}

class SoundBannerNotification : Notification() {
    override fun send() = super.send() + " with Sound and Banner"
}

class VibrationBannerNotification : Notification() {
    override fun send() = super.send() + " with Vibration and Banner"
}

// And so on...

Here, we need to create a new subclass for every combination:

• SoundNotification
• VibrationNotification
• BannerNotification
• SoundVibrationNotification
• SoundBannerNotification
• VibrationBannerNotification
• …and so on!

For three features, you end up with a lot of classes. This doesn’t scale well because for n features, you might need 2^n subclasses (combinations of features). This is called subclass explosion.

How Decorator Pattern Solves This (Using Inheritance + Composition)

With the Decorator Pattern, we use composition to dynamically wrap objects instead of relying on subclassing to mix behaviors.

Here’s the key difference:

• Inheritance is used only to ensure that both the base class (Notification) and the decorators (SoundNotificationDecorator, VibrationNotificationDecorator, etc.) implement the same interface.
• Composition is used to “wrap” objects with additional behavior dynamically, at runtime.

Let’s see how this works.

Decorator Pattern Rocks

First, we define the common interface (Notification) and the decorators:

// Step 1: Define the common interface (or abstract class)
interface Notification {
    fun send(): String
}

// Step 2: Implement the base notification class
class BasicNotification : Notification {
    override fun send() = "Sending Basic Notification"
}

// Step 3: Create the abstract decorator class, inheriting from Notification
abstract class NotificationDecorator(private val decoratedNotification: Notification) : Notification {
    override fun send(): String {
        return decoratedNotification.send() // Delegate to the wrapped object
    }
}

// Step 4: Implement concrete decorators
class SoundNotificationDecorator(notification: Notification) : NotificationDecorator(notification) {
    override fun send(): String {
        return super.send() + " with Sound"
    }
}

class VibrationNotificationDecorator(notification: Notification) : NotificationDecorator(notification) {
    override fun send(): String {
        return super.send() + " with Vibration"
    }
}

class BannerNotificationDecorator(notification: Notification) : NotificationDecorator(notification) {
    override fun send(): String {
        return super.send() + " with Banner"
    }
}

Here,

• Common Interface (Notification): Both the base class (BasicNotification) and the decorators (SoundNotificationDecorator, VibrationNotificationDecorator, etc.) implement the Notification interface. This is where we use inheritance.
• Composition: Instead of subclassing, each decorator contains another Notification object (which could be the base or another decorator) and wraps it with additional functionality.

Dynamic Behavior at Runtime (No Subclass Explosion)

Now, we can apply these decorators dynamically, without creating new subclasses for each combination:

fun main() {
    // Create a basic notification
    var notification: Notification = BasicNotification()

    // Dynamically add features at runtime using decorators
    notification = SoundNotificationDecorator(notification)
    notification = VibrationNotificationDecorator(notification)
    notification = BannerNotificationDecorator(notification)

    // Final notification with all features
    println(notification.send()) // Output: Sending Basic Notification with Sound with Vibration with Banner
}

Avoiding Subclass Explosion:

• Instead of creating a class for each combination (like SoundVibrationBannerNotification), we combine behaviors dynamically by wrapping objects.
• Using composition, we can mix and match behaviors as needed, avoiding the explosion of subclasses.

Dynamic Behavior:

• You can dynamically add or remove features at runtime by wrapping objects with decorators. For example, you can add sound, vibration, or banner as needed.
• This gives you flexibility because you don’t have to predefine all possible combinations in the class hierarchy.

Why Use Composition and Inheritance Together?

• Inheritance ensures that the decorators and the original object can be used interchangeably since they all implement the same interface (Notification).
• Composition lets us dynamically combine behaviors by wrapping objects instead of creating a new subclass for every possible feature combination.

In short, the Decorator Pattern uses inheritance to define a common interface and composition to avoid subclass explosion by dynamically adding behaviors. This combination provides the flexibility to enhance object behavior at runtime without the need for a rigid subclass hierarchy.

Real-Life Example — Enhancing a Banking Payment System with the Decorator Pattern

Imagine you’re developing a banking payment system that starts off simple — just basic payment processing for transactions. But as the bank expands its services, you need to introduce extra features, like transaction fees or fraud detection, while keeping the core payment logic intact. How do you manage this without creating a tangled mess? That’s where the Decorator Pattern comes in. Let’s break it down step by step, adding these new banking features while maintaining a clean and flexible architecture.

Note: This is just a simple example, but have you noticed similar trends with apps like GPay? When you recharge your mobile, you might encounter an extra platform fee. The same is true for apps like PhonePe, Flipkart, Swiggy, and more recently, Zomato, which raised platform fees during festive seasons like Diwali, where these fees have become increasingly common. Initially, these services offered simple, fee-free features. However, as the platforms evolved and expanded their offerings, additional layers — such as service fees and other enhancements — were introduced to support new functionalities. We don’t know exactly which approach they followed, but the Decorator Pattern would be a great fit for such use cases, as it allows for these additions without disrupting the core functionality.

Let’s design this system step by step using the Decorator Pattern.

Step 1: Defining the Component Interface

We will start by defining a simple PaymentProcessor interface. This interface will have a method processPayment() that handles the basic payment process.

interface PaymentProcessor {
    fun processPayment(amount: Double)
}

Step 2: Implementing the Concrete Component

The BasicPaymentProcessor class will be the concrete implementation of the PaymentProcessor interface. This class will simply process the payment without any additional behavior like fees or fraud checks.

class BasicPaymentProcessor : PaymentProcessor {
    override fun processPayment(amount: Double) {
        println("Processing payment of ₹$amount")
    }
}

This class represents the core logic for processing payments.

Step 3: Creating the Decorator Class

Now, we need to create an abstract class PaymentProcessorDecorator that will implement the PaymentProcessor interface and forward requests to the decorated object. This will allow us to add new behavior in subclasses.

abstract class PaymentProcessorDecorator(private val processor: PaymentProcessor) : PaymentProcessor {
    override fun processPayment(amount: Double) {
        processor.processPayment(amount)  // Forwarding the call to the wrapped component
    }
}

The PaymentProcessorDecorator acts as a wrapper for the original PaymentProcessor and can add extra functionality in the subclasses.

Step 4: Implementing the Concrete Decorators

Let’s now add two decorators:

1. TransactionFeeDecorator: This adds a fee to the payment.
2. FraudDetectionDecorator: This performs a fraud check before processing the payment.

Transaction Fee Decorator

This decorator adds a transaction fee on top of the payment amount.

class TransactionFeeDecorator(processor: PaymentProcessor) : PaymentProcessorDecorator(processor) {
    private val feePercentage = 2.5  // Let's assume a 2.5% fee on every transaction

    override fun processPayment(amount: Double) {
        val fee = amount * feePercentage / 100
        println("Applying transaction fee of ₹$fee")
        super.processPayment(amount + fee)  // Passing modified amount to the wrapped processor
    }
}

Fraud Detection Decorator

This decorator performs a simple fraud check before processing the payment.

class FraudDetectionDecorator(processor: PaymentProcessor) : PaymentProcessorDecorator(processor) {
    override fun processPayment(amount: Double) {
        if (isFraudulentTransaction(amount)) {
            println("Payment flagged as fraudulent! Transaction declined.")
        } else {
            println("Fraud check passed.")
            super.processPayment(amount)  // Proceed if fraud check passes
        }
    }

    private fun isFraudulentTransaction(amount: Double): Boolean {
        // Simple fraud detection logic: consider transactions above ₹10,000 as fraudulent for this example
        return amount > 10000
    }
}

Step 5: Using the Decorators

Now that we have both decorators ready, let’s use them. We’ll create a BasicPaymentProcessor and then decorate it with both TransactionFeeDecorator and FraudDetectionDecorator to show how these can be combined.

fun main() {
    val basicProcessor = BasicPaymentProcessor()

    // Decorate the processor with transaction fees and fraud detection
    val processorWithFees = TransactionFeeDecorator(basicProcessor)
    val processorWithFraudCheckAndFees = FraudDetectionDecorator(processorWithFees)

    // Test with a small payment
    println("Payment 1:")
    processorWithFraudCheckAndFees.processPayment(5000.0)

    // Test with a large (fraudulent) payment
    println("\nPayment 2:")
    processorWithFraudCheckAndFees.processPayment(20000.0)
}

Output

Payment 1:
Fraud check passed.
Applying transaction fee of ₹125.0
Processing payment of ₹5125.0

Payment 2:
Payment flagged as fraudulent! Transaction declined.

In this case,

1. Basic Payment Processing: We start with the BasicPaymentProcessor, which simply processes the payment.
2. Adding Transaction Fees: The TransactionFeeDecorator adds a fee on top of the amount and forwards the modified amount to the BasicPaymentProcessor.
3. Fraud Detection: The FraudDetectionDecorator checks if the transaction is fraudulent before forwarding the payment to the next decorator (or processor). If the transaction is fraudulent, it stops the process.

By using the Decorator Pattern, we can flexibly add more behaviors like logging, authentication, or currency conversion without modifying the original PaymentProcessor class. This avoids violating the Open-Closed Principle (OCP), where classes should be open for extension but closed for modification.

Why Use the Decorator Pattern?

1. Flexibility: The Decorator Pattern provides more flexibility than inheritance. Instead of creating many subclasses for every combination of features, we use a combination of decorators.
2. Open/Closed Principle: The core component class (like Cake, Notification and PaymentProcessor) remains unchanged. We can add new features (decorators) without altering existing code, making the system open for extension but closed for modification.
3. Single Responsibility: Each decorator has a single responsibility: to add specific behavior to the object it wraps.

When to Use the Decorator Pattern?

• When you want to add behavior to objects dynamically.
• When subclassing leads to too many classes and complicated hierarchies.
• When you want to follow the Open/Closed principle and extend an object’s functionality without modifying its original class.

Limitations of the Decorator Pattern

While the Decorator Pattern is quite powerful, it has its limitations:

• Increased Complexity: As the number of decorators increases, the system can become more complex to manage and understand, especially with multiple layers of decorators wrapping each other.
• Debugging Difficulty: With multiple decorators, it can be harder to trace the flow of execution during debugging.

Conclusion

The Decorator Design Pattern offers a versatile and dynamic approach to enhancing object behavior without the need for extensive subclassing. By allowing you to “wrap” objects with additional functionality, it promotes cleaner, more maintainable code and encourages reusability. Throughout this exploration in Kotlin, we’ve seen how this pattern can be applied to real-world scenarios, making it easier to adapt and extend our applications as requirements evolve. Whether you’re adding features to a simple object or constructing complex systems, the Decorator Pattern provides a powerful tool in your design toolkit. Embrace the flexibility it offers, and you’ll find that your code can be both elegant and robust!

Have you ever felt overwhelmed by complex systems in your software projects? You’re not alone! The Composite Design Pattern is here to help simplify those tangled webs, but surprisingly, it often gets overlooked. Many of us miss out on its benefits simply because we aren’t familiar with its basics or how to apply it in real-life scenarios.

But don’t worry—I’ve got your back! In this blog, I’ll walk you through the essentials of the Composite Design Pattern, breaking down its structure and showing you practical, real-world examples. By the end, you’ll see just how powerful this pattern can be for streamlining your code. So let’s jump right in and start making your design process easier and more efficient!

Composite Design Pattern

The Composite Design Pattern is a structural pattern that allows you to treat individual objects and compositions of objects uniformly. The pattern is particularly useful when you have a tree structure of objects, where individual objects and groups of objects need to be treated in the same way.

In short, it lets you work with both single objects and groups of objects in a similar manner, making your code more flexible and easier to maintain.

When to Use the Composite Design Pattern

The Composite pattern is super handy when you’re working with a bunch of objects that fit into a part-whole hierarchy.

Wait, what’s a part-whole hierarchy?

A part-whole hierarchy is basically a structure where smaller parts come together to form a larger system. It’s a way of organizing things so that each part can function on its own, but also as part of something bigger. Think of it like a tree or a set of nested boxes — each piece can be treated individually, but they all fit into a larger whole.

In software design, this idea is key to the Composite Design Pattern. It lets you treat both individual objects and collections of objects in the same way. Here’s how it works:

• Leaf objects: These are the basic, standalone parts that don’t contain anything else.
• Composite objects: These are more complex and can hold other parts, both leaf and composite, forming a tree-like structure.

You’ll find this in many places, like:

• UI Components: A window might have buttons, text fields, and panels. A panel can have more buttons or even nested panels inside.
• File Systems: Files and directories share similar operations — open, close, getSize, etc. Directories can hold files or other directories.
• Drawing Applications: A simple shape, like a circle or rectangle, can stand alone or be part of a bigger graphic made up of multiple shapes.

Now, let’s look at a simple example.

Imagine we’re building a graphic editor that works with different shapes — simple ones like circles, rectangles, and lines. But we also want to create more complex drawings by grouping these shapes together. The tricky part is that we want to treat both individual shapes and groups of shapes the same way. That’s where the Composite Pattern comes in handy.

Structure of the Composite Pattern

In the Composite Pattern, there are usually three key pieces:

• Component: This is an interface or abstract class that lays out the common operations that both simple objects and composite objects can perform.
• Leaf: This represents an individual object in the structure. It’s a basic part of the system and doesn’t have any children.
• Composite: This is a group of objects, which can include both leaves and other composites. It handles operations by passing them down to its children.

Composite Design Pattern in Kotlin

Now, let’s dive into how to implement the Composite Pattern in Kotlin.

We’ll model a graphics system where shapes like circles and rectangles are treated as Leaf components, and a group of shapes (like a drawing) is treated as a Composite.

Step 1: Defining the Component Interface

The first step is to define a Shape interface that all shapes (both individual and composite) will implement.

interface Shape {
    fun draw()
}

Step 2: Creating the Leaf Components

Now, let’s implement two basic shape classes: Circle and Rectangle. These classes will be the Leaf nodes in our Composite structure, meaning they do not contain any other shapes.

class Circle(private val name: String) : Shape {
    override fun draw() {
        println("Drawing a Circle: $name")
    }
}

class Rectangle(private val name: String) : Shape {
    override fun draw() {
        println("Drawing a Rectangle: $name")
    }
}

Here, both Circle and Rectangle implement the Shape interface. They only define the draw() method because these are basic shapes.

Step 3: Creating the Composite Component

Next, we will create a Composite class called Drawing, which can hold a collection of shapes (both Circle and Rectangle, or even other Drawing objects).

class Drawing : Shape {
    private val shapes = mutableListOf<Shape>()

    // Add a shape to the drawing
    fun addShape(shape: Shape) {
        shapes.add(shape)
    }

    // Remove a shape from the drawing
    fun removeShape(shape: Shape) {
        shapes.remove(shape)
    }

    // Drawing the entire group of shapes
    override fun draw() {
        println("Drawing a group of shapes:")
        for (shape in shapes) {
            shape.draw()  // Delegating the draw call to child components
        }
    }
}

Here’s what’s happening:

• Drawing class implements Shape and contains a list of Shape objects.
• It allows adding and removing shapes.
• When draw() is called on the Drawing, it delegates the drawing task to all the shapes in its list.

Step 4: Bringing It All Together

Now, let’s look at an example that demonstrates how the Composite pattern works in action.

fun main() {
    // Create individual shapes
    val circle1 = Circle("Circle 1")
    val circle2 = Circle("Circle 2")
    val rectangle1 = Rectangle("Rectangle 1")

    // Create a composite drawing of shapes
    val drawing1 = Drawing()
    drawing1.addShape(circle1)
    drawing1.addShape(rectangle1)

    // Create another drawing with its own shapes
    val drawing2 = Drawing()
    drawing2.addShape(circle2)
    drawing2.addShape(drawing1)  // Adding a drawing within a drawing

    // Draw the second drawing, which contains a nested structure
    drawing2.draw()
}

Output

Drawing a group of shapes:
Drawing a Circle: Circle 2
Drawing a group of shapes:
Drawing a Circle: Circle 1
Drawing a Rectangle: Rectangle 1

We first create individual Circle and Rectangle shapes.We then create a Drawing (composite) that contains circle1 and rectangle1.Finally, we create another composite Drawing that includes circle2 and even the previous Drawing. This shows how complex structures can be built from simpler components.

Real-World Examples

Now, let’s go further and explore a few more real-world examples.

Composite Pattern in Shopping Cart System

We’ll create a system to represent a product catalog, where a product can be either a single item (leaf) or a bundle of items (composite).

Step 1: Define the Component Interface

The Component defines the common operations. Here, the Product interface will have a method showDetails to display the details of each product.

// Component
interface Product {
    fun showDetails()
}

Step 2: Implement the Leaf Class

The Leaf class represents individual products, like a single item in our catalog.

// Leaf
class SingleProduct(private val name: String, private val price: Double) : Product {
    override fun showDetails() {
        println("$name: $price")
    }
}

In this class:

• name: Represents the product name.
• price: Represents the price of the product.

The showDetails method simply prints the product’s name and price.

Step 3: Implement the Composite Class

Now, let’s implement the Composite class, which can hold a collection of products (either single or composite).

// Composite
class ProductBundle(private val bundleName: String) : Product {
    private val products = mutableListOf<Product>()

    fun addProduct(product: Product) {
        products.add(product)
    }

    fun removeProduct(product: Product) {
        products.remove(product)
    }

    override fun showDetails() {
        println("$bundleName contains the following products:")
        for (product in products) {
            product.showDetails()
        }
    }
}

Here:

• The ProductBundle class maintains a list of Product objects.
• The addProduct method lets us add new products to the bundle.
• The removeProduct method lets us remove products from the bundle.
• The showDetails method iterates through each product and calls its showDetails method.

Step 4: Putting It All Together

Now that we have both single and composite products, we can build a catalog of individual items and bundles.

fun main() {
    // Individual products
    val laptop = SingleProduct("Laptop", 1000.0)
    val mouse = SingleProduct("Mouse", 25.0)
    val keyboard = SingleProduct("Keyboard", 75.0)

    // A bundle of products
    val computerSet = ProductBundle("Computer Set")
    computerSet.addProduct(laptop)
    computerSet.addProduct(mouse)
    computerSet.addProduct(keyboard)

    // Another bundle
    val officeSupplies = ProductBundle("Office Supplies")
    officeSupplies.addProduct(SingleProduct("Notebook", 10.0))
    officeSupplies.addProduct(SingleProduct("Pen", 2.0))

    // Master bundle
    val shoppingCart = ProductBundle("Shopping Cart")
    shoppingCart.addProduct(computerSet)
    shoppingCart.addProduct(officeSupplies)

    // Display details of all products
    shoppingCart.showDetails()
}

Here,

• We first create individual products (laptop, mouse, keyboard).
• Then, we group them into a bundle (computerSet).
• We create another bundle (officeSupplies).
• Finally, we add both bundles to a master bundle (shoppingCart).
• When calling shoppingCart.showDetails(), the Composite Pattern allows us to display all the products, both single and grouped, using the same showDetails() method.

Output

Shopping Cart contains the following products:
Computer Set contains the following products:
Laptop: 1000.0
Mouse: 25.0
Keyboard: 75.0
Office Supplies contains the following products:
Notebook: 10.0
Pen: 2.0

Composite Pattern in File System

Let’s implement the Composite Design Pattern in a file system where files and directories share common operations like opening, deleting, and renaming. In this scenario:

• Files are treated as individual objects (leaf nodes).
• Directories can contain both files and other directories (composite nodes).

Step 1: Define the FileSystemComponent Interface

The Component will be an interface that defines the common operations for both files and directories. We’ll include methods like open, delete, rename, and showDetails.

// Component
interface FileSystemComponent {
    fun open()
    fun delete()
    fun rename(newName: String)
    fun showDetails()
}

Step 2: Implement the File Class (Leaf)

The File class is a leaf node in the composite pattern. It represents individual files that implement the common operations defined in the FileSystemComponent interface.

// Leaf
class File(private var name: String) : FileSystemComponent {
    override fun open() {
        println("Opening file: $name")
    }

    override fun delete() {
        println("Deleting file: $name")
    }

    override fun rename(newName: String) {
        println("Renaming file from $name to $newName")
        name = newName
    }

    override fun showDetails() {
        println("File: $name")
    }
}

Step 3: Implement the Directory Class (Composite)

The Directory class is the composite node in the pattern. It can hold a collection of files and other directories. The directory class implements the same operations as files but delegates actions to its child components (files or directories).

// Composite
class Directory(private var name: String) : FileSystemComponent {
    private val contents = mutableListOf<FileSystemComponent>()

    fun add(component: FileSystemComponent) {
        contents.add(component)
    }

    fun remove(component: FileSystemComponent) {
        contents.remove(component)
    }

    override fun open() {
        println("Opening directory: $name")
        for (component in contents) {
            component.open()
        }
    }

    override fun delete() {
        println("Deleting directory: $name and its contents:")
        for (component in contents) {
            component.delete()
        }
        contents.clear()  // Remove all contents after deletion
    }

    override fun rename(newName: String) {
        println("Renaming directory from $name to $newName")
        name = newName
    }

    override fun showDetails() {
        println("Directory: $name contains:")
        for (component in contents) {
            component.showDetails()
        }
    }
}

Step 4: Putting It All Together

Now, let’s use the File and Directory classes to simulate a file system where directories contain files and possibly other directories.

fun main() {
    // Create individual files
    val file1 = File("file1.txt")
    val file2 = File("file2.txt")
    val file3 = File("file3.txt")

    // Create a directory and add files to it
    val dir1 = Directory("Documents")
    dir1.add(file1)
    dir1.add(file2)

    // Create another directory and add files and a subdirectory to it
    val dir2 = Directory("Projects")
    dir2.add(file3)
    dir2.add(dir1)  // Adding the Documents directory to the Projects directory

    // Display the structure of the file system
    dir2.showDetails()

    // Perform operations on the file system
    println("\n-- Opening the directory --")
    dir2.open()

    println("\n-- Renaming file and directory --")
    file1.rename("new_file1.txt")
    dir1.rename("New_Documents")

    // Show updated structure
    dir2.showDetails()

    println("\n-- Deleting directory --")
    dir2.delete()

    // Try to show the structure after deletion
    println("\n-- Trying to show details after deletion --")
    dir2.showDetails()
}

Here,

• We create individual files (file1.txt, file2.txt, and file3.txt).
• We create a directory Documents and add file1 and file2 to it.
• We create another directory Projects, add file3 and also add the Documents directory to it, demonstrating that directories can contain both files and other directories.
• We display the contents of the Projects directory, which includes the Documents directory and its files.
• We perform operations like open, rename, and delete on the files and directories.
• After deletion, we attempt to show the details again to verify that the contents are removed.

Output

Directory: Projects contains:
File: file3.txt
Directory: Documents contains:
File: file1.txt
File: file2.txt

-- Opening the directory --
Opening directory: Projects
Opening file: file3.txt
Opening directory: Documents
Opening file: file1.txt
Opening file: file2.txt

-- Renaming file and directory --
Renaming file from file1.txt to new_file1.txt
Renaming directory from Documents to New_Documents
Directory: Projects contains:
File: file3.txt
Directory: New_Documents contains:
File: new_file1.txt
File: file2.txt

-- Deleting directory --
Deleting directory: Projects and its contents:
Deleting file: file3.txt
Deleting directory: New_Documents and its contents:
Deleting file: new_file1.txt
Deleting file: file2.txt

-- Trying to show details after deletion --
Directory: Projects contains:

The Composite Pattern allows us to treat directories (composite objects) just like files (leaf objects). This means that operations such as opening, renaming, deleting, and showing details can be handled uniformly for both files and directories. The hierarchy can grow naturally, supporting nested structures where directories can contain files or even other directories. Overall, this implementation showcases how the Composite Design Pattern effectively models a real-world file system in Kotlin, allowing files and directories to share common behavior while maintaining flexibility and scalability.

Benefits of the Composite Pattern

• Simplicity: You can treat individual objects and composites in the same way.
• Flexibility: Adding or removing components is easy since they follow a consistent interface.
• Transparency: Clients don’t need to worry about whether they’re working with a single item or a composite.

Drawbacks

• Complexity: The pattern can introduce complexity, especially if it’s used in scenarios that don’t involve a natural hierarchy.
• Overhead: If not carefully implemented, it may lead to unnecessary overhead when dealing with very simple structures.

When to Use the Composite Pattern?

• When you want to represent part-whole hierarchies of objects.
• When you want clients to be able to treat individual objects and composite objects uniformly.
• When you need to build complex structures out of simpler objects but still want to treat the whole structure as a single entity.

Conclusion

And there you have it! We’ve unraveled the Composite Design Pattern together, and I hope you’re feeling inspired to give it a try in your own projects. It’s all about simplifying those complex systems and making your life a little easier as a developer.

As you move forward, keep an eye out for situations where this pattern can come in handy. The beauty of it is that once you start using it, you’ll wonder how you ever managed without it!

Thanks for hanging out with me today. I’d love to hear about your experiences with the Composite Design Pattern or any cool projects you’re working on. Happy coding, and let’s make our software as clean and efficient as possible!

A few days ago, I shared my thoughts on the Adapter Design Pattern—where I noticed it seamlessly bridges the gap between different systems. Now, as I dive into the Bridge Design Pattern, I see it’s more than just about bridging gaps; it’s about creating flexibility, decoupling abstraction from implementation, and making your code as adaptable as possible.

In this blog, we’ll explore:

• What exactly is the Bridge Design Pattern?
• Its structure and how it works under the hood
• Practical, real-world examples that bring the concept to life
• And perhaps most importantly, how it differs from the Adapter Pattern (because, yes, there’s a key difference!).

So, let’s dive in and discover what makes the Bridge Design Pattern a game-changer in clean, scalable software architecture.

What is the Bridge Design Pattern?

Let’s start with the basics: the Bridge Design Pattern is a structural pattern designed to decouple an abstraction from its implementation. By separating these two components, you can vary them independently, which enhances the system’s flexibility and scalability. This means you can extend either the abstraction or the implementation without disrupting the existing system.

In simpler terms, the Bridge Pattern allows you to modify what your code does without affecting how it does it. If that sounds confusing, don’t worry; it will become clearer as we go on.

Essentially, the Bridge Pattern promotes object composition over inheritance, making it particularly useful when dealing with complex class hierarchies that can lead to a proliferation of subclasses as variations increase.

Why is this important? As your project grows, you might find that every new feature requires adjustments to existing code, which can quickly lead to chaos. The Bridge Pattern helps you avoid this mess by keeping your code flexible and easier to manage.

Why Use the Bridge Design Pattern?

Here’s an example you might relate to: imagine you’re building a simple drawing app. You have different shapes—let’s say Circle and Rectangle. You also want to paint them in different colors, like Red and Green. Sounds easy, right? But if you approach this by creating classes like RedCircle, GreenRectangle, GreenCircle, etc., you’ll quickly end up with a ton of redundant classes.

                     Shape
                       |
       ----------------|----------------
      |                                 |
   Rectangle                          Circle
      |                                 |
   -------------                   -------------
  |             |                 |             |
RedRectangle  GreenRectangle   RedCircle    GreenCircle

With Bridge Pattern 

                    Shape                                                 
                      |
       ---------------|-----------------
      |                                 |
  Rectangle (Color)                 Circle (Color)
  
  
  
  

                            -------- Color ----------
                           |                         |
                         Red                       Green

Enter the Bridge Pattern. It allows you to keep the Shape and Color separate so that you can easily mix and match them without creating dozens of new classes. It’s like having a separate “shape drawer” and “color palette” that you can combine however you like.

Components of the Bridge Design Pattern

The Bridge Design Pattern is a structural pattern that decouples an abstraction from its implementation, allowing them to vary independently. This pattern is particularly useful when you want to avoid a proliferation of classes that arise from combining multiple variations of abstractions and implementations.

Here,

• Abstraction: This defines the abstract interface and contains a reference to the implementer. The abstraction typically provides a higher-level interface that clients use.
• Refined Abstraction: This extends the abstraction and may provide additional functionality or specificity. It can also override behaviors defined in the abstraction.
• Implementer: This defines the interface for the implementation classes. It does not have to match the abstraction interface; in fact, it can be quite different. The implementer interface can have multiple implementations.
• Concrete Implementers: These are specific implementations of the implementer interface. Each concrete implementer provides a different implementation of the methods defined in the implementer interface.

How the Bridge Pattern Works

1. Decoupling: The Bridge Pattern decouples the abstraction from the implementation. This means that you can change or extend either side independently.
2. Client Interaction: The client interacts with the abstraction interface, and the abstraction can delegate calls to the implementation without the client needing to know about it.
3. Flexibility: You can add new abstractions and implementations without modifying existing code, promoting adherence to the Open/Closed Principle.

Let’s take a more detailed example to illustrate how the Bridge Pattern works.

Example: Shapes and Colors

Scenario: You are building a drawing application that allows users to create shapes with different colors.

Abstraction: Shape

• Methods: draw()

Refined Abstraction: Circle and Rectangle

• Each shape has a draw() method that uses the color implementation.

Implementer: Color

• Method: fill()

Concrete Implementers: Red and Green

• Each color has a specific implementation of the fill() method.

// Implementer interface
interface Color {
    fun fill()
}

// Concrete Implementers
class Red : Color {
    override fun fill() {
        println("Filling with Red color.")
    }
}

class Green : Color {
    override fun fill() {
        println("Filling with Green color.")
    }
}

// Abstraction
abstract class Shape(protected val color: Color) {
    abstract fun draw()
}

// Refined Abstraction
class Circle(color: Color) : Shape(color) {
    override fun draw() {
        print("Drawing Circle. ")
        color.fill()
    }
}

class Rectangle(color: Color) : Shape(color) {
    override fun draw() {
        print("Drawing Rectangle. ")
        color.fill()
    }
}

// Client Code
fun main() {
    val redCircle: Shape = Circle(Red())
    redCircle.draw()  // Output: Drawing Circle. Filling with Red color.

    val greenRectangle: Shape = Rectangle(Green())
    greenRectangle.draw()  // Output: Drawing Rectangle. Filling with Green color.
}

• Separation of Concerns: The Bridge Pattern promotes separation of concerns by dividing the abstraction from its implementation.
• Flexibility and Extensibility: It provides flexibility and extensibility, allowing new abstractions and implementations to be added without modifying existing code.
• Avoiding Class Explosion: It helps in avoiding class explosion that occurs when you have multiple variations of abstractions and implementations combined together.

The Bridge Design Pattern is particularly useful in scenarios where you want to manage multiple dimensions of variability, providing a clean and maintainable code structure.

Real World Example

Let’s consider a scenario where we are building a notification system. We have different types of notifications (e.g., Email, SMS, Push Notification), and each notification can be sent for different platforms (e.g., Android, iOS).

If we don’t use the Bridge pattern, we might end up with a class hierarchy like this:

• AndroidEmailNotification
• IOSEmailNotification
• AndroidSMSNotification
• IOSMSNotification
• …

This quickly becomes cumbersome and difficult to maintain as the number of combinations increases. The Bridge Design Pattern helps us to handle such cases more efficiently by separating the notification type (abstraction) from the platform (implementation).

Before implementing, here’s a quick recap of what the components of the Bridge Pattern are.

1. Abstraction: Defines the high-level interface.
2. Refined Abstraction: Extends the abstraction and adds additional operations.
3. Implementor: Defines the interface for implementation classes.
4. Concrete Implementor: Provides concrete implementations of the implementor interface.

Let’s implement the Bridge Design Pattern in Kotlin for our notification system.

Step 1: Define the Implementor (Platform Interface)

interface NotificationSender {
    fun sendNotification(message: String)
}

The NotificationSender interface acts as the Implementor. It defines the method sendNotification() that will be implemented by concrete platform-specific classes.

Step 2: Concrete Implementors (Platform Implementations)

Now, we’ll create concrete classes that implement NotificationSender for different platforms.

class AndroidNotificationSender : NotificationSender {
    override fun sendNotification(message: String) {
        println("Sending notification to Android device: $message")
    }
}

class IOSNotificationSender : NotificationSender {
    override fun sendNotification(message: String) {
        println("Sending notification to iOS device: $message")
    }
}

Here, AndroidNotificationSender and IOSNotificationSender are Concrete Implementors. They provide platform-specific ways of sending notifications.

Step 3: Define the Abstraction (Notification)

Next, we define the Notification class, which represents the Abstraction. It contains a reference to the NotificationSender interface.

abstract class Notification(protected val sender: NotificationSender) {
    abstract fun send(message: String)
}

The Notification class holds a sender object that allows it to delegate the task of sending notifications to the appropriate platform implementation.

Step 4: Refined Abstractions (Different Types of Notifications)

Now, we’ll create refined abstractions for different types of notifications.

class EmailNotification(sender: NotificationSender) : Notification(sender) {
    override fun send(message: String) {
        println("Email Notification:")
        sender.sendNotification(message)
    }
}

class SMSNotification(sender: NotificationSender) : Notification(sender) {
    override fun send(message: String) {
        println("SMS Notification:")
        sender.sendNotification(message)
    }
}

Here, EmailNotification and SMSNotification extend the Notification class and specify the type of notification. They use the sender to send the actual message via the appropriate platform.

Step 5: Putting It All Together

Let’s see how we can use the Bridge Design Pattern in action:

fun main() {
    val androidSender = AndroidNotificationSender()
    val iosSender = IOSNotificationSender()

    val emailNotification = EmailNotification(androidSender)
    emailNotification.send("You've got mail!")

    val smsNotification = SMSNotification(iosSender)
    smsNotification.send("You've got a message!")
}

Output

Email Notification:
Sending notification to Android device: You've got mail!
SMS Notification:
Sending notification to iOS device: You've got a message!

What’s happening here?

• We created an AndroidNotificationSender and IOSNotificationSender for the platforms.
• Then, we created EmailNotification and SMSNotification to handle the type of message.
• Finally, we sent notifications to both Android and iOS devices using the same abstraction, but different platforms.

Advantages of Bridge Design Pattern

The Bridge Design Pattern provides several advantages:

• Decoupling Abstraction and Implementation: You can develop abstractions and implementations independently. Changes to one won’t affect the other.
• Improved Flexibility: The pattern allows you to extend either the abstraction or the implementation without affecting the rest of the codebase.
• Reduced Class Explosion: It prevents an explosion of subclasses that would otherwise occur with direct inheritance.
• Better Maintainability: Since abstraction and implementation are separated, code becomes cleaner and easier to maintain.

Adapter & Bridge: Difference in Intent

When it comes to design patterns, understanding the difference between the Adapter and Bridge patterns is crucial for effective software development. The Adapter pattern focuses on resolving incompatibilities between two existing interfaces, allowing them to work together seamlessly. In this scenario, the two interfaces operate independently, enabling them to evolve separately over time. However, the coupling between them can be unforeseen, which may lead to complications down the road. On the other hand, the Bridge pattern takes a different approach by connecting an abstraction with its various implementations. This pattern ensures that the evolution of the implementations aligns with the base abstraction, creating a more cohesive structure. In this case, the coupling between the abstraction and its implementations is well-defined and intentional, promoting better maintainability and flexibility. By understanding these distinctions, developers can choose the right pattern based on their specific needs, leading to more robust and adaptable code.

When to Use the Bridge Pattern

Consider using the Bridge Pattern in the following scenarios:

• When your system has multiple dimensions of variations (like different shapes and colors), and you want to minimize subclassing.
• When you need to decouple abstraction from implementation, allowing both to evolve independently.
• When you want to reduce the complexity of a class hierarchy that would otherwise grow out of control with multiple subclasses.

Conclusion

The Bridge Design Pattern is a lifesaver when you have multiple dimensions that need to change independently. By separating the abstraction (what you want to do) from the implementation (how you do it), this pattern ensures your code remains flexible, clean, and easy to extend.

In our notification system example, we applied the pattern, but it can also be used in countless other scenarios, such as database drivers, payment gateways, or even UI frameworks.

Hopefully, this guide has given you a solid understanding of the Bridge Pattern in Kotlin. I encourage you to implement it in your projects and feel free to adapt it as needed!

The Adapter Design Pattern is a developer’s secret weapon when it comes to making incompatible systems work together smoothly without altering their original code. Acting as a bridge, it allows different components to communicate effortlessly. If you’ve ever hit a roadblock where two pieces of code just wouldn’t “talk” to each other, then you’ve faced the exact challenge that the Adapter Pattern is designed to solve!

In this blog, we’re diving deep into everything about the Adapter Design Pattern—its structure, types (like Class and Object adapters), examples, real-world use cases, and how it’s applied in Android development. Whether you’re working with legacy systems or building new features, this pattern is key to simplifying integration and boosting code flexibility.

Grab a coffee mug—this blog’s going to be a big one! Get ready for a complete guide that will take your understanding of design patterns to the next level. Let’s get started!

What is the Adapter Design Pattern?

The Adapter Design Pattern helps connect two things that wouldn’t normally work together because they don’t “fit” or communicate the same way. It acts as a bridge that makes an existing class compatible with another class you need, without changing either one.

Think of it like using an adapter to plug something into an outlet that has a different shape—it allows them to work together without altering either the plug or the outlet.

Imagine you’re traveling in Europe with your US laptop. The European wall outlet provides 220 volts, while your laptop’s power adapter is designed for a standard AC plug and expects 110 volts. They’re incompatible, right? That’s where a power adapter steps in, converting the European outlet’s power to match what your laptop needs.

In software, the Adapter Pattern works in the same way. It allows two incompatible interfaces to work together without changing their core functionality. Just like the power adapter converts the outlet’s power, a software adapter “translates” between systems to make them compatible.

Instead of rewriting code, you create an adapter class that bridges the gap—keeping everything working smoothly.

In short, the Adapter Pattern is your go-to solution for making incompatible systems work together, just like your handy travel adapter!

Defination of Adapter Design Pattern

The Adapter design pattern (one of the structural design patterns) acts as a bridge between two incompatible interfaces. It allows an existing class (which has a specific interface) to be used with another class (which expects a different interface), without changing their existing code. It does this by creating an intermediary adapter class that translates the method calls from one interface to the other.

Why is the Adapter called ‘glue’ or ‘wrapper’?

Sometimes, a class has the features a client needs, but its way of interacting (interface) doesn’t match what the client expects. In these cases, we need to transform the existing interface into a new one that the client can work with, while still utilizing the original class.

Suppose you have an existing software system that requires integrating a new vendor library, but the new vendor has designed their interfaces differently from the previous vendor. What should you do? Write a class that adapts the new vendor’s interface to the one you’re expecting.

The Adapter Pattern helps us achieve this by creating a wrapper class around the original object. This wrapper is called an adapter, and the original object is known as the adaptee. The adapter acts as a bridge, allowing the client to use the adaptee’s functionality in a way that meets their needs.

To expand on this, the adapter is often referred to as “glue” because it metaphorically binds together two different interfaces, making them work smoothly as one. Similarly, it is called a “wrapper” because it encloses the original object (the adaptee) and presents a modified interface that the client can use without needing to change the original object.

The Structure of Adapter Pattern

The Adapter Design Pattern involves four components:

1. Target (Interface): The desired interface that the client expects.
2. Adaptee: The existing class that has the behavior we want to use but with an incompatible interface.
3. Adapter: A wrapper class that implements the Target interface and translates the requests from the client to the Adaptee.
4. Client: The entity that interacts with the Target interface.

Let’s revisit our example of a European wall socket and a US laptop’s AC plug for better understanding.

• Adaptee Interface: This is the existing interface or system that needs to be adapted. It has its own methods that may not be compatible with what the client expects.
• Target Interface: This is the interface that the client is designed to work with. The client will call methods from this interface.
• Request Method: This is the method defined in the target interface that the client will use.
• Adapter:
  The adapter acts as a bridge between the target interface and the adaptee interface. It implements the target interface and holds a reference to an instance of the adaptee. The adapter translates calls from the target interface into calls to the adaptee interface.
• Translated Request Method: This method in the adapter takes the request from the client and converts it into a format that the adaptee can understand.

Now, we have a EuropeanWallSocket that provides electricity in a format incompatible with a US laptop. We will create an adapter to make them compatible.

Step 1: Define the Adaptee Interface

This is the existing interface that represents the European wall socket.

// Adaptee interface
interface EuropeanWallSocket {
    fun provideElectricity(): String // Provides electricity in European format
}

// Implementation of the adaptee
class EuropeanWallSocketImpl : EuropeanWallSocket {
    override fun provideElectricity(): String {
        return "220V AC from European wall socket"
    }
}

Step 2: Define the Target Interface

This is the interface that our US laptop expects.

// Target interface
interface USLaptop {
    fun plugIn(): String // Expects a method to plug in
}

Step 3: Create the Adapter

The adapter will implement the target interface and use an instance of the adaptee.

// Adapter class
class SocketAdapter(private val europeanWallSocket: EuropeanWallSocket) : USLaptop {
    override fun plugIn(): String {
        // Adapt the European socket output for the US laptop
        val electricity = europeanWallSocket.provideElectricity()
        return "Adapting: $electricity to 110V AC for US laptop"
    }
}

Step 4: Client Code

Now, the client can use the USLaptop interface without worrying about the underlying EuropeanWallSocket.

fun main() {
    // Create an instance of the adaptee (European socket)
    val europeanSocket = EuropeanWallSocketImpl()

    // Use the adapter to connect the US laptop
    val socketAdapter = SocketAdapter(europeanSocket)

    // Plug in the US laptop using the adapter
    println(socketAdapter.plugIn())
}

Here,

1. Adaptee: The EuropeanWallSocket interface and its implementation, EuropeanWallSocketImpl, represent a wall socket that provides electricity in the European format (220V AC).
2. Target: The USLaptop interface defines the method the laptop uses to connect to a power source.
3. Adapter: The SocketAdapter class implements the USLaptop interface and contains an instance of EuropeanWallSocket. It adapts the output from the European wall socket to a format that the US laptop can understand (converting it to 110V AC).
4. Client: In the main function, we create an instance of the EuropeanWallSocketImpl, wrap it in the SocketAdapter, and call the plugIn method to simulate plugging in the US laptop.

Output

When you run this code, it will output:

Adapting: 220V AC from European wall socket to 110V AC for US laptop

This example is only for demonstration purposes, illustrating how the Adapter Pattern allows a US laptop to work with a European wall socket by adapting the interface, making the systems compatible without altering their original functionality.

Bridging the Gap: How the Adapter Pattern Facilitates Communication

Have you ever wondered how the Adapter Pattern bridges the gap? The answer lies in the use of object composition and the principle that the pattern binds the client to an interface rather than an implementation.

Delegation serves as the vital link that connects an Adapter to its Adaptee, facilitating seamless communication between the two. Meanwhile, interface inheritance defines the contract that the Adapter class must follow, ensuring clarity and consistency in its interactions.

Look at the previous example above: the client code binds to the USLaptop interface, not to the specific implementation of the adapter or the Adaptee. This design allows for flexibility; if you need to adapt to a different type of socket in the future, you can create a new adapter that implements the same USLaptop interface without changing the client code.

The Target and the Adaptee—often an older, legacy system—are established before the Adapter is introduced. The Adapter acts as a bridge, allowing the Target to utilize the Adaptee’s functionality without modifying its original structure. This approach not only enhances flexibility, but also elegantly encapsulates complexity, enabling developers to create more adaptable systems.

Adapter Pattern Variants

There are two common variants of the Adapter pattern:

• Object Adapter: The adapter holds an instance of the adaptee and delegates requests to it.
• Class Adapter: The adapter inherits from both the target and adaptee classes. However, Kotlin (like Java) does not support multiple inheritance, so this variant is less commonly used in Kotlin.

Object Adapters and Class Adapters use two different methods to adapt the Adaptee: composition and inheritance.

Let’s look at each one individually and discuss their differences.

Object Adapter Pattern

In the Object Adapter Pattern, the adapter contains an instance of the adaptee and implements the interface expected by the client. It “adapts” the methods of the adaptee to fit the expected interface.

Structure of Object Adapter Pattern

1. Client: The class that interacts with the target interface.
2. Target Interface: The interface that the client expects.
3. Adaptee: The class with an incompatible interface that needs to be adapted.
4. Adapter: The class that implements the target interface and holds a reference to the adaptee, enabling the two incompatible interfaces to work together.

In this UML diagram of the Object Adapter Pattern,

• Client → Depends on → Target Interface
• Adapter → Implements → Target Interface
• Adapter → Has a reference to → Adaptee
• Adaptee → Has methods incompatible with the Target Interface

Key Points:

• Object Adapter uses composition (by containing the adaptee) instead of inheritance, which makes it more flexible and reusable.
• The adapter doesn’t alter the existing Adaptee class but makes it compatible with the Target Interface.

Simple Example of Object Adapter Pattern

Let’s consider a simple scenario where we want to charge different types of phones, but their charging ports are incompatible.

1. The Client is a phone charger that expects to use a USB type-C charging port.
2. The Adaptee is an old phone that uses a micro-USB charging port.
3. The Adapter bridges the difference by converting the micro-USB interface to a USB type-C interface.

Step 1: Define the Target Interface

The charger (client) expects all phones to implement this interface (USB Type-C).

// Target interface that the client expects
interface UsbTypeCCharger {
    fun chargeWithUsbTypeC()
}

Step 2: Define the Adaptee

This is the old phone, which only has a Micro-USB port. The charger can’t directly use this interface.

// Adaptee class that uses Micro-USB for charging
class MicroUsbPhone {
    fun rechargeWithMicroUsb() {
        println("Micro-USB phone: Charging using Micro-USB port")
    }
}

Step 3: Create the Adapter

The adapter will “adapt” the Micro-USB phone to make it compatible with the USB Type-C charger. It wraps the MicroUsbPhone and translates the charging request.

// Adapter that makes Micro-USB phone compatible with USB Type-C charger
class MicroUsbToUsbTypeCAdapter(private val microUsbPhone: MicroUsbPhone) : UsbTypeCCharger {
    override fun chargeWithUsbTypeC() {
        println("Adapter: Converting USB Type-C to Micro-USB")
        microUsbPhone.rechargeWithMicroUsb() // Delegating the charging to the Micro-USB phone
    }
}

Step 4: Implement the Client

The client (charger) works with the target interface (UsbTypeCCharger). It can now charge a phone with a Micro-USB port by using the adapter.

fun main() {
    // Old phone with a Micro-USB port (Adaptee)
    val microUsbPhone = MicroUsbPhone()

    // Adapter that makes the Micro-USB phone compatible with USB Type-C charger
    val usbTypeCAdapter = MicroUsbToUsbTypeCAdapter(microUsbPhone)

    // Client (USB Type-C Charger) charges the phone using the adapter
    println("Client: Charging phone using USB Type-C charger")
    usbTypeCAdapter.chargeWithUsbTypeC()
}

Output:

Client: Charging phone using USB Type-C charger
Adapter: Converting USB Type-C to Micro-USB
Micro-USB phone: Charging using Micro-USB port

Here,

• Client: The charger expects all phones to be charged using a USB Type-C port, so it calls chargeWithUsbTypeC().
• Adapter: The adapter receives the request from the client to charge using USB Type-C. It converts this request and adapts it to the MicroUsbPhone by calling rechargeWithMicroUsb() internally.
• Adaptee (MicroUsbPhone): The phone knows how to charge itself using Micro-USB. The adapter simply makes it compatible with the client’s expectation.

Now, let’s look at another type, the Class Adapter Pattern.

Class Adapter Pattern

The Class Adapter Pattern is another type of adapter design pattern where an adapter class inherits from both the target interface and the Adaptee class. Unlike the Object Adapter Pattern, which uses composition (holding an instance of the Adaptee), the Class Adapter Pattern employs multiple inheritance to directly connect the client and the Adaptee.

In languages like Kotlin, which do not support true multiple inheritance, we simulate this behavior by using interfaces. The adapter implements the target interface and extends the Adaptee class to bridge the gap between incompatible interfaces.

Before going into much detail, let’s first understand the structure of the Class Adapter Pattern.

Structure of Class Adapter Pattern

1. Client: The class that interacts with the target interface.
2. Target Interface: The interface that the client expects to interact with.
3. Adaptee: The class with an incompatible interface that needs to be adapted.
4. Adapter: A class that inherits from both the target interface and the adaptee, adapting the adaptee to be compatible with the client.

In this UML diagram of the Class Adapter Pattern,

• Client → Depends on → Target Interface
• Adapter → Inherits from → Adaptee
• Adapter → Implements → Target Interface
• Adaptee → Has methods incompatible with the target interface

Key Points:

• The Class Adapter pattern relies on inheritance to connect the Adaptee and the Target Interface.
• The adapter inherits from the adaptee and implements the target interface, thus combining both functionalities.

Simple Example of Class Adapter Pattern 

Now, let’s look at an example of the Class Adapter Pattern. We’ll use the same scenario: a charger that expects a USB Type-C interface but has an old phone that only supports Micro-USB.

Step 1: Define the Target Interface

This is the interface that the client (charger) expects.

// Target interface that the client expects
interface UsbTypeCCharger {
    fun chargeWithUsbTypeC()
}

Step 2: Define the Adaptee

This is the class that needs to be adapted. It’s the old phone with a Micro-USB charging port.

// Adaptee class that uses Micro-USB for charging
class MicroUsbPhone {
    fun rechargeWithMicroUsb() {
        println("Micro-USB phone: Charging using Micro-USB port")
    }
}

Step 3: Define the Adapter (Class Adapter)

The Adapter inherits from the MicroUsbPhone (adaptee) and implements the UsbTypeCCharger (target interface). It adapts the MicroUsbPhone to be compatible with the UsbTypeCCharger interface.

// Adapter that inherits from MicroUsbPhone and implements UsbTypeCCharger
class MicroUsbToUsbTypeCAdapter : MicroUsbPhone(), UsbTypeCCharger {
    // Implement the method from UsbTypeCCharger
    override fun chargeWithUsbTypeC() {
        println("Adapter: Converting USB Type-C to Micro-USB")
        // Call the inherited method from MicroUsbPhone
        rechargeWithMicroUsb() // Uses the Micro-USB method to charge
    }
}

Step 4: Client Usage

The Client only interacts with the UsbTypeCCharger interface and charges the phone through the adapter.

fun main() {
    // Adapter that allows charging a Micro-USB phone with a USB Type-C charger
    val usbTypeCAdapter = MicroUsbToUsbTypeCAdapter()

    // Client (USB Type-C Charger) charges the phone through the adapter
    println("Client: Charging phone using USB Type-C charger")
    usbTypeCAdapter.chargeWithUsbTypeC()
}

Output:

Client: Charging phone using USB Type-C charger
Adapter: Converting USB Type-C to Micro-USB
Micro-USB phone: Charging using Micro-USB port

Here,

• Client: The client expects all phones to be charged using the UsbTypeCCharger interface.
• Adapter: The adapter class inherits the behavior of the MicroUsbPhone (adaptee) and implements the UsbTypeCCharger interface. It converts the USB Type-C charging request and delegates it to the inherited rechargeWithMicroUsb() method.
• Adaptee (Micro-USB phone): The MicroUsbPhone class has a method to recharge using Micro-USB, which is directly called by the adapter.

Class Adapter Vs. Object Adapter

The main difference between the Class Adapter and the Object Adapter lies in how they achieve compatibility between the Target and the Adaptee. In the Class Adapter pattern, we use inheritance by subclassing both the Target interface and the Adaptee class, which allows the adapter to directly access the Adaptee’s behavior. This means the adapter is tightly coupled to both the Target and the Adaptee at compile-time.

On the other hand, the Object Adapter pattern relies on composition, meaning the adapter holds a reference to an instance of the Adaptee rather than inheriting from it. This approach allows the adapter to forward requests to the Adaptee, making it more flexible because the Adaptee instance can be changed or swapped without modifying the adapter. The Object Adapter pattern is generally preferred when more flexibility is needed, as it loosely couples the adapter and Adaptee.

In short, the key difference is that the Class Adapter subclasses both the Target and the Adaptee, while the Object Adapter uses composition to forward requests to the Adaptee.

Real-World Examples

We’ll look at more real-world examples soon, but before that, let’s first explore a structural example of the Adapter Pattern to ensure a smooth understanding.

Adapter Pattern: Structural Example

Since we’ve already seen many code examples, there’s no rocket science here. Let’s jump straight into the code and then go over its explanation.

// Target interface that the client expects
interface Target {
    fun request()
}

// Adaptee class that has an incompatible method
class Adaptee {
    fun delegatedRequest() {
        println("This is the delegated method.")
    }
}

// Adapter class that implements Target and adapts Adaptee
class Adapter : Target {
    private val delegate = Adaptee() // Composition: holding an instance of Adaptee

    // Adapting the request method to call Adaptee's delegatedRequest
    override fun request() {
        delegate.delegatedRequest()
    }
}

// Test class to demonstrate the Adapter Pattern
fun main() {
    val client: Target = Adapter() // Client interacts with the Adapter through the Target interface
    client.request() // Calls the adapted method
}

////////////////////////////////////////////////////////////

// OUTPUT

// This is the delegated method.

In the code above,

• Target interface: The interface that the client expects to interact with.
• Adaptee class: Contains the method delegatedRequest(), which needs to be adapted to the Target interface.
• Adapter class: Implements the Target interface and uses composition to hold an instance of Adaptee. It adapts the request() method to call delegatedRequest().
• Client: Uses the adapter by interacting through the Target interface.

Here, the Adapter adapts the incompatible interface (Adaptee) to the interface the client expects (Target), allowing the client to use the Adaptee without modification.

Adapting an Enumeration to an Iterator

In the landscape of programming, particularly when dealing with collections in Kotlin and Java, we often navigate between legacy enumerators and modern iterators. In Java, the legacy Enumeration interface features straightforward methods like hasMoreElements() to check for remaining elements and nextElement() to retrieve the next item, representing a simpler time. In contrast, the modern Iterator interface—found in both Java and Kotlin—introduces a more robust approach, featuring hasNext(), next(), and even remove() (In Kotlin, the remove() method is part of the MutableIterator<out T> interface) for effective collection management.

Despite these advancements, many applications still rely on legacy code that exposes the Enumeration interface. This presents developers with a dilemma: how to seamlessly integrate this outdated system with newer code that prefers iterators. This is where the need for an adapter emerges, bridging the gap and allowing us to leverage the strengths of both worlds. By creating an adapter that implements the Iterator interface while wrapping an Enumeration instance, we can provide a smooth transition to modern coding practices without discarding the functionality of legacy systems.

Let’s examine the two interfaces

Adapting an Enumeration to an Iterator begins with examining the two interfaces. The Iterator interface includes three essential methods: hasNext(), next(), and remove(), while the older Enumeration interface features hasMoreElements() and nextElement(). The first two methods from Enumeration map easily to Iterator‘s counterparts, making the initial adaptation straightforward. However, the real challenge arises with the remove() method in Iterator, which has no equivalent in Enumeration. This disparity highlights the complexities involved in bridging legacy code with modern practices, emphasizing the need for an effective adaptation strategy to ensure seamless integration of the two interfaces.

Designing the Adapter

To effectively bridge the gap between the old-world Enumeration and the new-world Iterator, we will utilize methods from both interfaces. The Iterator interface includes hasNext(), next(), and remove(), while the Enumeration interface offers hasMoreElements() and nextElement(). Our goal is to create an adapter class, EnumerationIterator, which implements the Iterator interface while internally working with an existing Enumeration. This design allows our new code to leverage Iterators, even though an Enumeration operates beneath the surface. In essence, EnumerationIterator serves as the adapter, transforming the legacy Enumeration into a modern Iterator for your codebase, ensuring seamless integration and enhancing compatibility.

Dealing with the remove() Method

The Enumeration interface is a “read-only” interface that does not support the remove() method. This limitation implies that there is no straightforward way to implement a fully functional remove() method in the adapter. The best approach is to throw a runtime exception, as the Iterator designers anticipated this need and implemented an UnsupportedOperationException for such cases.

EnumerationIterator Adapter Code

Now, let’s look at how we can convert all of this into code.

import java.util.Enumeration
import java.util.Iterator

// EnumerationIterator class implementing Iterator
// Since we are adapting Enumeration to Iterator, 
// the EnumerationIterator must implement the Iterator interface 
// -- it has to look like the Iterator.
class EnumerationIterator<T>(private val enumeration: Enumeration<T>) : Iterator<T> {
    
    // We are adapting the Enumeration, using composition to store it in an instance variable.
    
    // hasNext() and next() are implemented by delegating to the corresponding methods in the Enumeration. 
    
    // Checks if there are more elements in the enumeration
    override fun hasNext(): Boolean {
        return enumeration.hasMoreElements()
    }

    // Retrieves the next element from the enumeration
    override fun next(): T {
        return enumeration.nextElement()
    }

    // For remove(), we simply throw an exception.
    override fun remove() {
        throw UnsupportedOperationException("Remove operation is not supported.")
    }
}

Here,

• Generic Type: The EnumerationIterator class is made generic with <T> to handle different types of enumerations.
• Constructor: The constructor takes an Enumeration<T> object as a parameter.
• hasNext() Method: This method checks if there are more elements in the enumeration.
• next() Method: This method retrieves the next element from the enumeration.
• remove() Method: This method throws an UnsupportedOperationException, indicating that the remove operation is not supported.

Here’s how we can use it,

fun main() {
    val list = listOf("Apple", "Banana", "Cherry")
    val enumeration: Enumeration<String> = list.elements()

    val iterator = EnumerationIterator(enumeration)
    
    while (iterator.hasNext()) {
        println(iterator.next())
    }
}

Here, you can see how the EnumerationIterator can be utilized to iterate over the elements of an Enumeration. Please note that the elements() method is specific to classes like Vector or Stack, so ensure you have a valid Enumeration instance to test this example.

While the adapter may not be perfect, it provides a reasonable solution as long as the client is careful and the adapter is well-documented. This clarity ensures that developers understand the limitations and can work with the adapter effectively.

Adapting an Integer Set to an Integer Priority Queue

Transforming an Integer Set into a Priority Queue might sound tricky since a Set inherently doesn’t maintain order, while a Priority Queue relies on element priority. However, by using the Adapter pattern, we can bridge this gap. The Adapter serves as an intermediary, allowing the Set to be used as if it were a Priority Queue. It adds the necessary functionality by reordering elements based on their priority when accessed. This way, you maintain the uniqueness of elements from the Set, while enabling the prioritized behavior of a Priority Queue, all without modifying the original structures. This approach enhances code flexibility and usability.

I know some of you might still be a little confused. Before we dive into the adapter code, let’s quickly revisit the basics of priority queues and integer sets. After that, we’ll walk through how we design the adapter, followed by the code and explanations.

What is a Priority Queue?

A Priority Queue is a type of queue in which elements are dequeued based on their priority, rather than their insertion order. In a typical queue (like a regular line), the first element added is the first one removed, which is known as FIFO (First In, First Out). However, in a priority queue, elements are removed based on their priority—typically the smallest (or sometimes largest) value is removed first.

• Example of Priority Queue Behavior: Imagine a hospital emergency room. Patients aren’t necessarily treated in the order they arrive; instead, the most critical cases (highest priority) are treated first. Similarly, in a priority queue, elements with the highest (or lowest) priority are processed first.In a min-priority queue, the smallest element is dequeued first. In a max-priority queue, the largest element is dequeued first.

What is an Integer Set?

A Set is a collection of unique elements. In programming, an Integer Set is simply a set of integers. The key characteristic of a set is that it does not allow duplicate elements and typically has no specific order.

• Example of Integer Set Behavior: If you add the integers 3, 7, 5, 3 to a set, the set will only contain 3, 7, 5, as the duplicate 3 will not be added again.

How Does the Integer Set Adapt to Priority Queue Behavior?

A Set by itself does not have any priority-based behavior. However, with the help of the Adapter pattern, we can make the set behave like a priority queue. The Adapter pattern is useful when you have two incompatible interfaces and want to use one in place of the other.

Here, the Set itself doesn’t manage priorities, but we build an adapter around the set that makes it behave like a Priority Queue. Specifically, we implement methods that will:

1. Add elements to the set (add() method).
2. Remove the smallest element (which gives it the behavior of a min-priority queue).
3. Check the size of the set, mimicking the size() behavior of a queue.

PriorityQueueAdapter : Code 

Now, let’s see the code and its explanations

// Define a PriorityQueue interface
interface PriorityQueue {
    fun add(element: Any)
    fun size(): Int
    fun removeSmallest(): Any?
}

// Implement the PriorityQueueAdapter that adapts a Set to work like a PriorityQueue
class PriorityQueueAdapter(private val set: MutableSet<Int>) : PriorityQueue {

    // Add an element to the Set
    override fun add(element: Any) {
        if (element is Int) {
            set.add(element)
        }
    }

    // Get the size of the Set
    override fun size(): Int {
        return set.size
    }

    // Find and remove the smallest element from the Set
    override fun removeSmallest(): Int? {
        // If the set is empty, return null
        if (set.isEmpty()) return null

        // Find the smallest element using Kotlin's built-in functions
        val smallest = set.minOrNull()

        // Remove the smallest element from the set
        if (smallest != null) {
            set.remove(smallest)
        }

        // Return the smallest element
        return smallest
    }
}

PriorityQueue Interface:

• We define an interface PriorityQueue with three methods:
• add(element: Any): Adds an element to the queue.
• size(): Returns the number of elements in the queue.
• removeSmallest(): Removes and returns the smallest element from the queue.

PriorityQueueAdapter Class:

• This is the adapter that makes a MutableSet<Int> work as a PriorityQueue. It adapts the Set behavior to match the PriorityQueue interface.
• It holds a reference to a MutableSet of integers, which will store the elements.

add() method:

• Adds an integer to the Set. Since Set ensures that all elements are unique, duplicate values will not be added.

size() method:

• Returns the current size of the Set, which is the number of elements stored.

removeSmallest() method:

• This method first checks if the set is empty; if so, it returns null.
• If not, it uses the built-in Kotlin method minOrNull() to find the smallest element in the set.
• Once the smallest element is found, it is removed from the set using remove(), and the smallest element is returned.

PriorityQueueAdapter: How It Works

Let’s walk through how the PriorityQueueAdapter works by using a simple example, followed by detailed explanations.

fun main() {
    // Create a mutable set of integers
    val integerSet = mutableSetOf(15, 3, 7, 20)

    // Create an instance of PriorityQueueAdapter using the set
    val priorityQueue: PriorityQueue = PriorityQueueAdapter(integerSet)

    // Add elements to the PriorityQueue
    priorityQueue.add(10)
    priorityQueue.add(5)

    // Print the size of the PriorityQueue
    println("Size of the PriorityQueue: ${priorityQueue.size()}") // Expected: 6 (15, 3, 7, 20, 10, 5)

    // Remove the smallest element
    val smallest = priorityQueue.removeSmallest()
    println("Smallest element removed: $smallest") // Expected: 3 (which is the smallest in the set)

    // Check the size of the PriorityQueue after removing the smallest element
    println("Size after removing smallest: ${priorityQueue.size()}") // Expected: 5 (remaining: 15, 7, 20, 10, 5)

    // Remove the next smallest element
    val nextSmallest = priorityQueue.removeSmallest()
    println("Next smallest element removed: $nextSmallest") // Expected: 5

    // Final state of the PriorityQueue
    println("Remaining elements in the PriorityQueue: $integerSet") // Expected: [15, 7, 20, 10]
}