O — From SOLID principles 2/5

By adminPublished On: March 13, 2023Categories: Development

Hey Folks,

Wondering where is O coming from and S is lost somewhere? No worries you can check the first article of this series.

Welcome to part two of this one of my favorite series of SOLID principles.

Thanks to Robert C. Martin for giving us these principles who help us a lot in designing beautiful code that helps in Accessibility, Refactoring, Extensibility, Debugging, and Readability.
Open and close principle

This principle states that your classes should be open for extension and close for modification. it’s hard to understand sometimes especially for new software engineers. But no problem I’ve all those necessary items that will help you understand this principle easily.

Let’s discuss this in more detail. Let’s just forget about software for a while, this principle can be applied to many domains. Your system should be adaptive and should have got the ability to accept new entries so that we don’t have to re-create our whole system or modify some part of our system.

But why the modification is considered bad? and extension is considered good for a system?

The reason for this question is simple. When you try to modify something in a system you need to consider all dependencies of given modification and system breaks most of the time.

But what happens in the case of extension?

If you are trying to extend something you do actually not change any functionality but you add a new feature without modification so the rest of the system should remain un-attended.

Sounds friendly? No? No problem I’ve got an example for you in the form of code as well.

Let’s consider a small program that helps us calculate the area of the given Shape.

/**
 * Created by Umair on 08,August,2021
 **/

class AreaCalculator {

    fun calculateArea(shapes : List) = shapes.sumOf {
        if (it is Square)
            it.side * it.side
        else if (it  is Circle)
            (it.radius * it.radius * Math.PI).toInt()
        else
            0
    }
}

class Square(val side : Int) : Shape
class Circle(val radius : Int) : Shape

//Shape interface
interface Shape

The above document has an issue. When a new shape will be introduced in our system. We will have to modify our calculator to accept new changes so there is a problem and the code won’t welcome new changes easily.

After the introduction of the new Shape Rectangle, our code will look like the below gist

class AreaCalculator {

    fun calculateArea(shapes : List) = shapes.sumOf {
        if (it is Square)
            it.side * it.side
        else if (it  is Circle)
            (it.radius * it.radius * Math.PI).toInt()
        else if (it  is Rectangle)
            it.width * it.height
        else
            0
    }
}

class Square(val side : Int) : Shape
class Circle(val radius : Int) : Shape
class Rectangle(val width : Int, val height : Int) : Shape

//Shape interface
interface Shape

You can see the difference in both code snippets that we are constantly changing our calculator whenever there is a new feature/shape.

Hence our system is not closed for modification at all 🙁

So how to fix this problem? No worries I’ve got a sample for that solution as well. Check this code demonstrating the right approach to solve this problem.


/**
 * Created by Umair on 08,August,2021
 */

class AreaCalculator {

    // Your method will become one liner :) you can add thousands of shapes and your area calculator
    // wont have to add extra word in it
    fun calculateArea(shapes : List) = shapes.sumOf { it.area() }
}

class Square(val side : Int) : Shape {
    override fun area() = side * side
}

class Rectangle(val height : Int,
                val width : Int) : Shape {
    override fun area() = height * width
}

class Circle(val radius : Int) : Shape {
    override fun area() = (radius * radius * Math.PI).toInt()
}

//Shape interface
interface Shape {
    fun area() : Int //Added interface method
}

Boom !!! You can see your area calculator method becomes a one-liner method and it is accepting all kinds of shapes for area calculation.

You can see how SOILD makes life easier.

Thanks for the read and for supporting me. See you in the next article with Part 3. If you still haven’t check part1. I would suggest you give it a read as well.

You can also check the git repository as well containing code files of the whole series

Bye!!