SOLID Principles in Android Development with Kotlin

Table of contents

• Introduction
• Single Responsibility Principle
• Open-Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle
• Conclusion

Introduction

Are you an Android developer? If yes, then you must have heard of SOLID principles. These principles are essential for designing robust, maintainable, and flexible software. But what are these principles exactly? And why are they crucial in Android development?

SOLID principles are a set of five principles that were introduced to make software designs more understandable and easier to maintain. They are important in Android development as they ensure that the code is scalable and maintainable in the long run. In this blog, I’ll give you an overview of these principles with examples of how they can be applied in Android development.

Single Responsibility Principle

The Single Responsibility Principle (SRP) states that every class should have only one responsibility. In other words, a class should have only one reason to change. It makes the class more flexible and easier to understand. In Android development, SRP can be applied by dividing the app’s responsibilities into different layers such as data access, business logic, and presentation layer. Each layer should have its own set of classes that have only one responsibility. For example, the ViewModel in Android is responsible only for managing the UI-related data and handling user interactions. This gives the class a clear and specific responsibility, making it easier to maintain and modify. By applying SRP, we can improve the overall quality of the Android app and make it easier to understand and maintain in the long run.

Violation of Single Responsibility Principle:

In a violation of the Single Responsibility Principle, a class or module takes on multiple responsibilities. This can lead to code that’s hard to maintain, inflexible, and error-prone.

class ViolatingProductManager(private val context: Context) {
    private val products = mutableListOf<Product>()

    fun fetchAndDisplayProducts() {
        // Fetch products from a server.
        val products = fetchProductsFromServer()

        // Display products in a RecyclerView.
        val recyclerView = RecyclerView(context)
        val adapter = ProductListAdapter(products)
        recyclerView.adapter = adapter
    }

    fun fetchProductsFromServer(): List<Product> {
        // Implementation to fetch products from the server.
        return emptyList()
    }

    fun saveProductsToDatabase(products: List<Product>) {
        // Implementation to save products to the local database.
    }
}

Correct Usage of Single Responsibility Principle:

In compliance with the Single Responsibility Principle, each class or module should have a single, well-defined responsibility, making the code more maintainable and extensible.

// Class responsible for managing product data
class ProductRepository {
    fun fetchProducts(): List<Product> {
        // Fetch products from a server or database.
    }

    fun saveProducts(products: List<Product>) {
        // Save products to a database.
    }
}

In this improved design, the responsibilities of fetching and displaying products are separated into distinct classes, adhering to the Single Responsibility Principle. The ProductRepository is responsible for data operations, and the ProductListActivity is focused on UI presentation and interaction, leading to cleaner and more maintainable code.

Open-Closed Principle

The Open-Closed Principle (OCP) states that a software entity should be open for extension but closed for modification. In simpler terms, it means that once a class has been written and tested, its implementation should not be changed to add new features, rather new features should be implemented by adding new code. In Android development, we can implement this principle by using inheritance, polymorphism, and interfaces. By creating abstract classes or interfaces, we can define a base structure that can be extended by other classes without modifying the base class. For example, if we have a class that displays images, we can make it open for extension by defining an interface that specifies the image format to be used. By creating a class that implements this interface, we can add support for new image formats without modifying the original class. By following the Open-Closed Principle, we can ensure that our code is easier to maintain and extend, and less prone to bugs.

Violation of Open-Closed Principle:

In a violation of the Open-Closed Principle, existing code is modified to accommodate new functionality. This leads to potential bugs and increased maintenance efforts.

class ProductService {
    fun calculateTotalPrice(cart: List<Product>, discount: Double): Double {
        var totalPrice = 0.0
        for (product in cart) {
            totalPrice += product.price
        }

        // Apply discount
        totalPrice *= (1.0 - discount)

        return totalPrice
    }
}

Correct Usage of Open-Closed Principle:

In compliance with the Open-Closed Principle, the code should be open for extension but closed for modification, allowing new functionality to be added without altering existing code.

interface PriceCalculator {
    fun calculateTotalPrice(cart: List<Product>): Double
}

class BasicPriceCalculator : PriceCalculator {
    override fun calculateTotalPrice(cart: List<Product>): Double {
        var totalPrice = 0.0
        for (product in cart) {
            totalPrice += product.price
        }
        return totalPrice
    }
}

class DiscountedPriceCalculator : PriceCalculator {
    override fun calculateTotalPrice(cart: List<Product>): Double {
        val basicCalculator = BasicPriceCalculator()
        val totalPrice = basicCalculator.calculateTotalPrice(cart)

        // Apply discount
        return totalPrice * (1.0 - discount)
    }
}

In this example, the Open-Closed Principle is followed. The PriceCalculator interface is open for extension, allowing the addition of new calculators (e.g., DiscountedPriceCalculator) without modifying existing code, thus promoting maintainability and flexibility.

Liskov Substitution Principle

The Liskov Substitution Principle (LSP) states that subclasses should be able to replace their superclass without changing the behavior of the overall system. An example of LSP in Android development is creating specialized subclasses of a parent class. By doing this, we can ensure that the subclasses can be substituted for their superclass without changing the behavior of the overall system.

Violation of Liskov Substitution Principle:

A violation of the Liskov Substitution Principle occurs when a subclass does not behave as a true subtype of its parent class, causing unexpected behavior and violating the contract established by the parent class.

open class Bird {
    open fun fly() {
        // Default flying behavior
    }
}

class Ostrich : Bird() {
    override fun fly() {
        // Ostriches can't fly, but they must implement the method
        throw UnsupportedOperationException("Ostriches can't fly")
    }
}

Correct Usage of Liskov Substitution Principle:

In compliance with the Liskov Substitution Principle, a subclass should be a true subtype of its parent class, meaning it must adhere to the contract established by the parent class.

open class Bird {
    open fun move() {
        // Default movement behavior
    }
}

class Ostrich : Bird() {
    override fun move() {
        // Ostriches move by running, which is consistent with the parent class
    }
}

In this example, the Ostrich class adheres to the Liskov Substitution Principle by providing a move() method that aligns with the behavior expected from its parent class, Bird. This ensures that the subclass can be used as a true subtype without unexpected behavior, promoting code reliability and maintainability.

Interface Segregation Principle

The Interface Segregation Principle (ISP) is one of the SOLID principles in Android development with Kotlin. It states that no client should be forced to depend on methods it does not use. In other words, we should not create big interfaces with unnecessary methods. Instead, we should break down the interfaces into smaller ones, with methods specific to each client. For example, imagine an animal interface with methods describing behaviors. Some animals can fly, while some cannot. So, to fix this, we create a separate interface for flying animals, which only the relevant clients would implement. This way, we can avoid unnecessary dependencies. In Android development, ISP is crucial to ensure that our code is flexible, maintainable, and scalable. By breaking down the interfaces into smaller ones, we can also reduce the chances of breaking changes when updating our code.

Violation of Interface Segregation Principle:

A violation of the Interface Segregation Principle occurs when a class is forced to implement methods it doesn’t need. This leads to unnecessary dependencies and bloated classes.

interface Worker {
    fun work()
    fun eat()
}

class SuperWorker : Worker {
    override fun work() {
        // SuperWorker's work behavior
    }

    override fun eat() {
        // SuperWorker's eating behavior
    }
}

Correct Usage of Interface Segregation Principle:

In compliance with the Interface Segregation Principle, interfaces should be tailored to the needs of the classes that implement them, avoiding unnecessary methods.

interface Workable {
    fun work()
}

interface Eatable {
    fun eat()
}

class SuperWorker : Workable, Eatable {
    override fun work() {
        // SuperWorker's work behavior
    }

    override fun eat() {
        // SuperWorker's eating behavior
    }
}

In this example, the Interface Segregation Principle is followed by breaking the original Worker interface into more specific interfaces (Workable and Eatable). This allows classes like SuperWorker to implement only the methods they need, reducing unnecessary dependencies and ensuring that classes adhere to their interfaces more closely.

Dependency Inversion Principle

Dependency Inversion Principle (DIP) is an essential principle in SOLID principles when it comes to Android development with Kotlin. This principle promotes the idea that high-level modules should not depend on low-level modules. In contrast, both modules should depend on abstractions. Abstraction should not depend on details; instead, it should be the other way around. A perfect example of DIP in Android development is when we develop an application for both the Android and iOS platforms. We can create an interface where the AndroidDeveloper and IOSDeveloper classes implement it rather than depending on their own platform and programming language. Following DIP in Android development can result in more flexible code and help prevent costly refactoring in the future.

Violation of Dependency Inversion Principle:

A violation of the Dependency Inversion Principle occurs when high-level modules depend on low-level modules, rather than both depending on abstractions. This leads to rigid and tightly coupled code.

class LightBulb {
    fun turnOn() {
        // Implementation to turn on the light bulb
    }
}

class Switch {
    private val bulb = LightBulb()

    fun control() {
        bulb.turnOn()
    }
}

Correct Usage of Dependency Inversion Principle:

In compliance with the Dependency Inversion Principle, both high-level and low-level modules should depend on abstractions, not on concrete implementations.

interface Switchable {
    fun turnOn()
}

class LightBulb : Switchable {
    override fun turnOn() {
        // Implementation to turn on the light bulb
    }
}

class Switch(private val device: Switchable) {
    fun control() {
        device.turnOn()
    }
}

In this example, the Dependency Inversion Principle is followed. The Switch class now depends on the abstraction Switchable, allowing for more flexibility and making it possible to switch different types of devices (not just light bulbs) without modifying the Switch class. This promotes decoupling and maintainability.

Conclusion

SOLID principles are essential in Android development with Kotlin to improve the maintainability and quality of the code. SRP, OCP, LSP, ISP, and DIP each have their respective applicability in achieving this. Following these principles will result in a less error-prone application that is easy to maintain and extend. The reusability of code is another one of the various advantages of applying these principles.