SOLID Design Principles: Learn the Open-Closed Principle

👋 Hey there, fellow software program fans!
I am Revisto, a passionate software program engineer, and I need to dive into the thrilling world of SOLID ideas.

SOLID is a algorithm and ideas that may assist us create maintainable, reusable, and versatile software program designs. Primarily, it gives pointers for constructing software program that may assist our initiatives develop simply.

So, what does SOLID stand for? Let’s break it down:

• S: Single Duty Precept
• O: Open-Closed Precept
• L: Liskov Substitution Precept
• I: Interface Segregation Precept
• D: Dependency Inversion Precept

✨ One of many basic ideas of SOLID is the Open-Closed Precept (OCP). It states that a category, technique, or operate ought to be open for extension however closed for modification. In different phrases, w*e ought to be capable to simply lengthen the performance of a software program element with out having to switch its present code.*

So, what does it imply for a element to be open for extension? It signifies that we are able to add new options or behaviors to the element with out modification. This may be achieved by way of strategies like inheritance, the place we are able to create new lessons or features that construct upon the prevailing ones.

By adhering to the Open-Closed Precept, we create software program parts which are versatile and adaptable🤩. When new necessities or options come up, we are able to merely lengthen the prevailing codebase relatively than modify it. This reduces the danger of introducing bugs and makes our software program extra maintainable in the long term.

Let’s check out a few examples for instance the Open-Closed Precept in motion:

👨‍💻 Instance: Inheritance

def calculate(earnings, deduction, nation):
    # tax_amount variable is outlined
    # in every calculation
    tax_amount = int()
    taxable_income = earnings - deduction
    if nation == "India":
        # calculation right here
        go
    elif nation == "US":
        # calculation right here
        go
    elif nation == "UK":
        # calculation right here
        go
    return tax_amount

❌ The calculate operate does not adhere to the Open-Closed Precept. Once we take into consideration scaling and customers from a number of international locations begin utilizing the app, then there could be an issue.
When that occurs, the TaxCalculator class wants to vary to help the brand new international locations and their guidelines. Thus, the present design violates OCP.

from abc import ABC, abstractmethod

class CountryTaxCalculator(ABC):
    @abstractmethod
    def calculate_tax_amount(self):
        go

class TaxCalculatorForUS(CountryTaxCalculator):
    def __init__(self, total_income, total_deduction):
        self.total_income = total_income
        self.total_deduction = total_deduction

    def calculate_tax_amount(self):
        taxable_income = self.total_income - self.total_deduction
        # calculation right here 
        return taxable_income 


class TaxCalculatorForUK(CountryTaxCalculator):
    def __init__(self, total_income, total_deduction):
        self.total_income = total_income
        self.total_deduction = total_deduction

    def calculate_tax_amount(self):
        taxable_income = self.total_income - self.total_deduction
        # calculation right here 
        return taxable_income

Extra examples at my GitHub

Adhering to the only accountability precept is essential. Ensure that every class or module has a transparent and distinct accountability. If a category turns into answerable for a number of duties, it is a signal that it ought to be damaged down into smaller, extra targeted items.

Open-Closed Precept VS Single-Duty Precept

Right here I quote from this post from sanderarts:

The Single Duty Precept offers with the truth that if a category has a number of obligations, these obligations might be tightly coupled in the event that they’re in a single class. So if an interface or algorithm modifications for one accountability it is going to probably additionally have an effect on the opposite accountability, an undesired impact.
Within the Open/Closed Precept a category ought to be capable to lengthen its habits with out the necessity to modify the category itself. The one want to switch the category ought to be as a result of it has a bug/error in it, not since you wish to change or add performance.

By embracing the Open-Closed Precept, we create software program that’s extra versatile, maintainable, and extensible. We will simply add new options with out modifying present code, selling code reuse and lowering the danger of introducing bugs. So, let’s attempt to maintain our software program open for extension however closed for modification!

🚀 Keep tuned for extra articles the place we’ll discover the opposite SOLID ideas and delve into the thrilling world of software program engineering.

Thanks for studying. Be happy to remark your ideas😊. Hope this submit was useful. You may hit me up on Linked In and Github.

Completely happy coding!