SOLID Principles: Explanation and examples – Cybarlab

SOLID is the quick type of 5 necessary design rules when doing OOD. It helps to make software program designs extra comprehensible, simpler to take care of and simpler to increase. As an excellent software program engineer, these 5 rules are important to know.

SOLID Principles
SOLID stands for:

• S -Single Responsibility Principle (SRP)
• O -Open Closed Principle (OCP)
• L -Liskov Substitution Principle (LSP)
• I -Interface Segregation Principle (ISP)
• D -Dependency Inversion Principle (DIP)

Single Responsibility Principle (SRP)

This precept states that software program entities (lessons, modules, features, and so forth.) will carry out just one job.

class Customer
 {
    void CreateCustomer(Database db, string custMessage)
    {
        strive
        {
            db.Add(custMessage);
        }
        catch (Exception ex)
        {
            db.LogError("An error occured: ", ex.ToString());
            File.WriteAllText("LocalErrors.txt", ex.ToString());
        }
    }
 }

Note that, right here CreateCustomer() technique has an excessive amount of duty. It create new buyer, saver error within the database, write error log in a file. This violates the only duty precept. Let’s appropriate it.

class Customer
 {
    personal ErrorLog errorLog = new ErrorLog();

    void CreateCustomer(Database db, string custMessage)
    {
        strive
        {
            db.Add(custMessage);
        }
        catch (Exception ex)
        {
            errorLog.log(ex.ToString())
        }
    }
 }

class ErrorLog
 {
    void log(string error)
    {
      db.LogError("An error occured: ", error);
      File.WriteAllText("LocalErrors.txt", error);
    }
 }

Now we’ve two lessons that every has one responsibly/job.

Open Closed Principle (OCP)

This precept states that software program entities (lessons, modules, features, and so forth.) must be open for extensions, however closed for modification. That means, we’ve to compose our class in such a approach that, we will reuse it with none modification.

class Customer
 {
    void CreateCustomer(Database db, string custMessage)
    {
        if (custMessage.StartsWith("#"))
        {
            db.AddAsTag(custMessage);
        }
        else
        {
            db.Add(custMessage);
        }
    }
 }

Here, we have to begin a tag with the character “#”. If we wish to use “@” or others character we’ve to switch our code. This is a violation of open shut principal. To overcome this we’ve to switch our codes.

class Customer
 {
    void CreateCustomer(Database db, string custMessage)
    {
        db.Add(custMessage);
    }
 }

class TagCustomer : Customer
 {
    override void CreateCustomer(Database db, string custMessage)
    {
        db.AddAsTag(custMessage);
    }
 }

Liskov Substitution Principle (LSP)

This rules states that if A is a subtype of B, then objects of sort B could also be changed (or substituted) with objects of sort A

Interface Segregation Principle

(ISP)This principal states that don’t add further performance to an current interface by including new strategies. Instead of that, create a brand new interface and let your class implement a number of interfaces if wanted.

interface ICustomer
 {
    void CreateCustomer();
 }

interface ICustomerNew
 {
    void CreateCustomer();
    void LearnCustomer();
 }

In the above code we violate the interface segregation precept. To overcome this we have to modify our codes.

interface ICustomerCreate
 {
    void CreateCustomer();
 }

interface ICustomerLearn
 {
    void LearnCustomer();
 }

Dependency Inversion Principle (DIP)

This principal states that high-level modules shouldn’t depend upon low-level modules. Both ought to depend upon abstractions. Abstractions shouldn’t depend upon particulars. Details ought to depend upon abstractions. We can solved this through the use of dependency injection.

class Customer
 {
    personal ErrorLog errorLog = new ErrorLog();

    void CreateCustomer(Database db, string custMessage)
    {
        strive
        {
            db.Add(custMessage);
        }
        catch (Exception ex)
        {
            errorLog.log(ex.ToString())
        }
    }
}

Here we create ErrorLog  occasion contained in the Customer class. This is a violation of the dependency inversion precept. To overcome it, we have to modify our code.

class Customer
 {
    personal ErrorLog _errorLog ;

    public Customer(ErrorLog errorLog )
    {
        _errorLog = errorLog ;
    }

    void CreateCustomer(Database db, string custMessage)
    {
        strive
        {
            db.Add(custMessage);
        }
        catch (Exception ex)
        {
            _errorLog.log(ex.ToString())
        }
    }
}

By utilizing dependency injection we now not depend on the Customer class to outline the particular sort of ErrorLog.

This 5 stable rules are very important and utilized by the software program engineers all around the globe. By making use of these you may make a reusable, maintainable, scalable code. We ought to attempt to apply these.