S.O.L.I.D Principles.

 S.O.L.I.D: The First 5 Principles of Object-Oriented Design.

by Jeewantha Hiddalarachchi.

Introduction of SOLID principles.

If you are already familiar with Object-Oriented Programming, you should have some idea about SOLID principles.

Assume that situation, when you build software using a bad design technique, your code can be inflexible and not understandable. If you are a professional and have to hand over your software project to another developer to move your project forward, you will automatically get him in trouble. As a result, finally, you can get an output with bugs because small mistakes can be generated bugs. Therefore every software developer should have knowledge about those SOLID principles.

The SOLID principle is a mnemonic acronym for five design principles. Those five principles guides to understandable, flexible, reusable, testable, and maintainable. This concept founded by American software engineer and instructor Robert C. Martin whos also known as Uncle Bob.

SOLID is not just a single word and it stands for:

• S - Single-responsibility Principle.
• O - Open-Closed Principle.
• L - Liskov Substitution Principle.
• I - Interface Segregation Principle.
• D - Dependency Inversion Principle.

From this article, you can get the basic knowledge about each principle individually and SOLID will grow up you as a perfect software developer.

Single-Responsibility Principle (SRP).

"A class should have one and only one reason to change, meaning that a class should have only one job."

The Single Responsibility principle states that a class should have only one responsibility or one purpose. But It does not mean each class should have one method or a function. So all the methods should relate to the whole class and they should work for the same goal. 

If a class has more responsibilities, it helps to make the complexity of the code and as a result, it helps to create bugs in your code. The reason is when you change the responsibility of a class, It affects another class also.

Therefore the best practice is If you have a class that has more responsibilities, You should create it as a separate new class.

Goals

Aims to separate methods and reduce the bugs when you change the method responsibilities. Therefore your change will not affect other methods.

Class Diagram Example:

Open-Closed Principle (OCP).

"Objects or entities should be open for extension, but closed for modification." - Meyer, Bertrand (1988). Object-Oriented Software Construction.

If you are extending your software entities or objects (like modules, classes, functions, etc.) by adding additional methods, you should do that without changing the contents of your original class. 

Assume you changed one method of a class without caring about other classes or a whole system, this change definitely affects other classes which are functioned with this changed class. Finally, that change affects the whole system. 

As a result, Bertrand Meyer proposed a solution for avoiding the above situation by using Object-Oriented generalization (especially implementation inheritance):

"A class is closed, since it may be compiled, stored in a library, baselined, and used by client classes. But it is also open, since any new class may use it as a parent, adding new features. When a descendant class is defined, there is no need to change the original or to disturb its clients." - Meyer, Bertrand (1988). Object-oriented software construction. New York: Prentice-Hall. p. 229.

Therefore the best practice is If you want to add a function to the class for enhancing the performance of the class, you should do that to exist class without change.

Goals

Aims to extend a class function without changing exists class functions. Because of that this extended class can be used anywhere and It also helps to avoid cause bugs.

Class Diagram Example:

Liskov Substitution Principle (LSP).

"Every subclass/derived class should be able to substitute their parent/base class."

Liskov Substitution Principle is a particular definition of subtyping relation and it can be called behavioral subtyping. This principle was introduced by Barbara Liskov in her conference keynote "Data abstraction" in 1987. 

First, we want to get an idea about what Substitution is. Assume, if S is a subtype of T, then objects of type T may be replaced with objects of type S without changing any of the desirable properties of the program.

As this substitution definition, we can simply say this principle created based on generalization theory in Object-Oriented programming (OOP). To get more knowledge, in 1994, Barbara Liskov and Jeannette Wing describe this principle summarization in their paper as follows:

Subtype Requirement: Let  be a property provable about objects  of type T. Then  should be true for objects  of type S where S is a subtype of T.

I will explain this principle like this. If you have a class and you created another class by using exist. Therefore exact class becomes a parent class and the new class becomes a child class. This process called Inheritance or generalization in OOP.

A child class can not perform as same as the parent class because the child class has some additional object/s than the parent class. But the class of children should be able to execute the same requests and give the same result to the parent class, or it may be given the same type of results.

If a child class doesn't fulfill those requirements, we can assume this mentioned new class is not a child of the existing class and as a result, we can say this situation violates the Liskov substitution principle.

Goals

Aims to perform the parent Class or its child Class in the same way without any errors.

Class Diagram Example:

Interface Segregation Principle (ISP).

"Client should not be forced to implement methods they do not use." - Martin, Robert (2002). Agile Software Development: Principles, Patterns, and Practices. Pearson Education.

The Interface Segregation Principle was first used and formulated by Robert C. Martin while consulting for Xerox which had created a new printer system that could perform multiple tasks like stapling, faxing, etc.

We can use interfaces for separate functionality of the system and provide protection for each separated functionalities by reaching unauthorized users or perform unauthorized actions. According to this principle, interfaces are used to divide a system into smaller and larger parts according to its specifications.

Assume, If a class performs some actions which are wasteful, they may have some ability to make bugs in the system. Therefore every class should perform actions that help to fulfill their roles. So it helps to reduce system code complexity too.  

Goals

Aims to split a set of functions into small sets, and execute what really wanted actions from functions.

Class Diagram Example:

Dependency Inversion Principle (DIP).

The Dependency Inversion Principle is specifically used to form loosely coupling software modules.

Conventional dependency relationships based on higher-level modules (or class) for low-level modules (or class), dependent modules are reversed. Not only that, high-level modules are independent of the implemented details in low-level modules.

According to Robert. C. Martin, this principle states:

1. "High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., interfaces).
2. Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions." - Martin, Robert C. (2003). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. pp. 127–131.

Let's identify the principle, by knowing the terms simply.

A class that executes an action by using tools is called a Higher Level module and the tool which is useful for performing an action is called a Lower Level module. And Abstraction is used to represent 

an interface which used to connect two classes and Details is describing the tool working procedure. 

So simple definition of this principle is:

Class (higher-level modules) should not couple with a tool (low-level class) tightly and permanently because a tool can not use to performs all actions and a tool can perform one action. Therefore class should couple with tools by using an interface. The class, therefore, has the ability to change tools based on the tasks to be performed. And also tools need to find their specific interface to perform as the class requires because either class or interface does not know about the tool's working procedure.

Goals

Aims to reduce high-level module dependency on low-level modules by using interfaces. 

Class Diagram Example:

Summary.

We discussed SOLID principles and their goals. And also know about how they are helping to your whole code in the system easy to understand, and how they are helping to maintain, reuse and upgrade your code easily without making any bugs.  

Thank you very much for reading and I hope you have a better idea about this topic...😊.