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: