DEV Community: Kumar Rishi

SOLID Principles for Android

Kumar Rishi — Tue, 11 Jun 2024 18:07:45 +0000

In this article we will see the remaining Principles,
if you haven't went through the first two principle
refer its first part.

L - Liskov Substitution Principle (LSP)

This principle says that we need to ensure that subclasses can replace their base classes without altering the correctness of the program.

Here its objective is , whenever we use subclasses, it should be substitutable in a manner it should not give any error and ofcourse should work without changing the base class behaviour.

Let's take a real example - Say a store have generic payment system, having payment processed and refund processed category, now say store wants to include a new payment system Gift card, so here refund is not allowed, so if this giftCard throws exception on invoking refundProcess then it violates the LSP principle.

You can correct it as :

interface Payment{
    fun paymentProcessed()
}

interface Refund{
    fun refundProcessed()
}

class CashPayment : Payment,Refund {
    override fun paymentProcessed() {
        println("Cash Payment Processed")
    }

    override fun refundProcessed() {
        println("Cash Refund Processed")
    }
}

class GiftCardPayment : Payment,Refund {
    override fun paymentProcessed() {
        println("Gift Card Payment Processed")
    }

    override fun refundProcessed() {
        println("Refund for GiftCard is Not Supported")
    }
}

Here it may look like, we can avoid directly but in big scenario, we need to ensure the if there is any restriction for one of the subclasses, it should execute without any exception.

I - Interface Segregation Principle (ISP)

Probably the easiest principle to understand,
This principle says that, the methods that are declared in the interface should not be forced to implement, if its subclass doesn't requires it.

Lets say a person can do many jobs like engineer, doctor, Civil service, but treating a patient is not something engineers can do, so to adhere with ISP, we can create separate interfaces from person then we can use them.

interface Person {
    fun engineer()

    fun doctor()

    fun teacher()
}

class Engineer : Person {
    override fun engineer() {
        println("Engineering")
    }
}

here this code will give error, as engineer class should not implement other methods, but here it is forced to.
To fix this


interface Person {
    fun engineer(){}

    fun doctor(){}

    fun teacher(){}
}

class Engineer : Person {
    override fun engineer() {
        println("Engineering")
    }
}

Here this code is just an example on how you can adhere to ISP.

D - Dependency Inversion Principle

This principle says that, for any implementations, we should depend on their abstractions and not on their concrete implementation.

For this i will give two examples,
first is, If you are following Android best practices, then you might have noticed that, if you have repository in your app then in your UI layer you were using repository abstraction and in data layer, you were using that repositoryImplementation, this is one example of DIP,

another example would be, say you are using authentication methods in your app, then instead of having a concrete extension, you can make it abstract and then use its function.

This helps in various ways, first your UI layer or whoever is using the abstraction will only know what is happening and how it is happening will be hidden. second when you use generic abstraction, it gives you a vast way of implementation on how that abstraction should work.

Let's see with the code,


class LoginMethod(
    private val firebaseAuth: FirebaseAuth,
    private val fieldValidator: FieldValidator,
    private val errorHandler: ErrorHandler
) {
    fun signIn(email: String, password: String) {
        // Authentication
        try {
            firebaseAuth.signInWithEmailAndPassword(email, password)
            println("Login successful")
        } catch (e: Exception) {
            // Error handling
            errorHandler.handleError(e)
        }
    }
}

Here the Firebase Auth is concrete implementation, now it has two cons, first your subclass is also aware of how it is working second if you want to use other authentications, we are restricted to do so here.

Let's Fix it

class LoginMethod(
    private val authentication: Authenticator,
    private val fieldValidator: FieldValidator,
    private val errorHandler: ErrorHandler
) {
    fun signIn(email: String, password: String) {
        // Authentication
        try {
            authentication.signInWithEmailAndPassword(email, password)
            println("Login successful")
        } catch (e: Exception) {
            // Error handling
            errorHandler.handleError(e)
        }
    }
}

interface Authenticator{
    fun signInWithEmailAndPassword(email: String, password: String)

    fun signInWithGoogle()
}

class AuthImpl(
    private val firebaseAuth: FirebaseAuth
) : Authenticator {
    override fun signInWithEmailAndPasswordWithFirebase(email: String, password: String) {
        firebaseAuth.signInWithEmailAndPassword(email, password)
    }

    override fun signInWithGoogle() {
        signInWithGoogle()
    }
}

Hope till now, if you are with me, this article might have helped you in understanding these principles. But in order to make it muscle memory you need to start using these principles.
If you have any suggestions, open for any discussions.

SOLID Principles for Android

Kumar Rishi — Sun, 09 Jun 2024 09:19:25 +0000

As a developer, there comes a time when we have to learn principles for moving ahead in career. For some this topic might be new, for some they are already experienced on these principles. I will try to make sure, this article may come in help for both of them.

So Let's Begin,

Every letter in SOLID , represents one principle.

The Fist Principle that we will talk about

S - Single Responsibility Principle ( SRP )

This one is easy to understand, but it might take you some time to get in memory muscle.

Real world Example - Let's say you are a chef in a restaurant, now you should be responsible for making the food right.
Now if you given also the task of handling the staffs in kitchen or serving food, will make the work complicated right.

That's how in programming, a method that you have declared should be assigned with only one responsibility and that is the only reason it should change. In this manner it will make code more convincible, workable and readable.

For ex :

class Chef{
    fun cook(){
        println("Cooking")
    }

    fun orderIngredients(){
        println("Ordering Ingredients")
    }

    fun manageStaff(){
        println("Managing Staff")
    }
}

fun main(){
    val chef = Chef()
    chef.cook()
    chef.orderIngredients()
    chef.manageStaff()
}

// but
// chef should only cook

class Chef1{
    fun cook(){
        println("Cooking")
    }
}

class Manager{
    fun orderIngredients(){
        println("Ordering Ingredients")
    }

    fun manageStaff(){
        println("Managing Staff")
    }
}

let's take an example of common usecase, when we are handling the authentication for our app,


class LoginMethod(
    private val firebaseAuth: FirebaseAuth
) {
    fun signIn(email: String, password: String) {
        // Input validation
        if (email.isEmpty() || password.isEmpty()) {
            throw IllegalArgumentException("Invalid input")
        }

        // Authentication
        try {
            firebaseAuth.signInWithEmailAndPassword(email, password)
            println("Login successful")
        } catch (e: Exception) {
            // Error handling
            println("Login failed: ${e.message}")
        }
    }
}

Here we are making this signIn function to handle more responsibility than it should do, like validating the fields and handling errors also

Here's how you can fix it,

class LoginMethod(
    private val firebaseAuth: FirebaseAuth,
    private val fieldValidator: FieldValidator,
    private val errorHandler: ErrorHandler
) {
    fun signIn(email: String, password: String) {
        // Input validation
        if(!fieldValidator.validateEmail(email) || !fieldValidator.validatePassword(password)) {
            throw IllegalArgumentException("Invalid Format")
        }

        // Authentication
        try {
            firebaseAuth.signInWithEmailAndPassword(email, password)
            println("Login successful")
        } catch (e: Exception) {
            // Error handling
            errorHandler.handleError(e)
        }
    }
}

class FieldValidator {
    fun validateEmail(email: String): Boolean {
        return email.contains("@")
    }

    fun validatePassword(password: String): Boolean {
        return password.length >= 6
    }
}

class ErrorHandler {
    fun handleError(e: Exception) {
        println("An error occurred: ${e.message}")
    }
}

Here our signIn function can only be responsible for login , not for checking validation or logging error.

Open/ Closed Principle ( OCP )

Here this principle states that, a class should open for extension but closed for modification.

Let's take an example

Real world example , say there is a car and it has music system which can play music via usb.
Now say, music system nowadays are coming with bluetooth connectivity also, then the engineers will not open each part of this music system, and install bluetooth module and close it, right. For one time it should feel convenient but for large case definitely not.
Instead they can extend one common module, where any new modules like BLE, WiFi can be connected, in this way they don't have to modify the system every time.

Let's understand with programming,

open class Shape {
    open fun draw() {
        println("Drawing Shape")
    }
}

Here if we want to change this class for every different shape, then it might change the code for the whole app, wherever you are using this.
Here intention is we should not modify how the class behaves or works.
so in this case , the class Shape should not be modified to accomodate new types of shapes


open class Shape {
    open fun draw() {
        println("Drawing Shape")
    }
    open fun drawSquare() {
        println("Drawing Shape")
    }
    open fun drawRect() {
        println("Drawing Shape")
    }
}

Instead you can modify this as


open class Shape {
    open fun draw() {
        println("Drawing Shape")
    }
}

class Square : Shape() {
    override fun draw() {
        println("Drawing Square")
    }
}

class Circle : Shape() {
    override fun draw() {
        println("Drawing Circle")
    }
}

Will post other principles very soon, till then if you have any suggestion, i'm open to any discussion.

Jetpack Compose -Difference between mutableStateOf() and derivedStateOf()

Kumar Rishi — Wed, 29 May 2024 13:07:27 +0000

Hey Guys!!, Well thought of sharing my experience on those concepts, which might gets overlooked quite frequently.
Have You ever wondered the exact usecase of mutableStateOf() and derivedStateOf()

Let's say when you have some variable and you want to trigger an UI change basically recomposition , when that variable changes, most likely you will use mutableStateOf()



val count = mutableStateOf(1)

However to make sure recomposition value must be stored you need to use remember, maybe next time i will focus on this

Now think of a situation, where you are storing some value, on that value change you automatically want to modify other variable, then derivedStateOf() is preferable
for ex :-



val height by remember{ mutableStateOf(10) }
val width by remember{ mutableStateOf(10) }
val area by remember{ derivedStateOf(height * width) }

in this way area will automatically change whenever there is any change in dimensions variables and composable observing area will also trigger recomposition.
In this manner it becomes more readable, less error prone

Now you may think this can be achieved by mutableStateOf() with something like



val height by remember{ mutableStateOf(10) }
val width by remember{ mutableStateOf(10) }
val area by remember{ mutableState(height * width) }

Here if there is any change in height and width , you need to manually update it



area = height * width

You can also do this by



val height by remember{ mutableStateOf(10) }
val width by remember{ mutableStateOf(10) }
val area by remember(height,width){ mutableState(height * width) }

now if there is any change in height and weight , area will also update

but here also the main difference is restricting composition count , when you are having long calculations and variable that changes very frequently,

Lets end this with my supporting word for last statement,
where i found this good example at StackOverFlow



@Composable
fun CounterButton() {
    val clicks = remember { mutableStateOf(0) }
    val counter = remember(clicks.value / 5) { mutableStateOf(clicks.value / 5) }

    Button(
        onClick = { clicks.value++ }
    ) {
        Text("${counter.value} clicked")
    }
}

counter variable is supposed to be change on every 5 clicks, say you pressed 30 clicks so then button will recompose on every click but the CounterButton() method will compose 5 times,



@Composable
fun CounterButton() {
    val clicks = remember { mutableStateOf(0) }
    val counter = remember { derivedStateOf { clicks.value / 5 } }

    Button(
        onClick = { clicks.value++ }
    ) {
        Text("${counter.value} clicked")
    }
}

here CounterButton() will have no recomposition,
But there is a huge pitfall or drawback for this, as it will not change the reference of the state object instead rely on state value.
You can learn more here - DerivedState Pitfall

Already the article went long, but if you are here, Thanks a lot for you time and if you want to update any fact , logic to lets bombard comment section and happy coding.