SOLID PRINCIPLES
Solid Principles are all basic approaches in software development processes and a set of 5 basic principles in general.
SOLİD PRINCIPLES
1. Single Responsibility Principle
2. Open/Closed Principle
3. Liskov ‘s Substitution Principle
4. Interface Segregation Principle
5. Dependency Inversion Principle
- Single Responsibility Principle
- Each class or method should have only one responsibility.
- The main point is “ Do one thing and do it best. “
We can ask this questions ourselves when we are start or continue to coding.
“Should this method be inside this class?”
“Is it the job of this method or class to perform this task?”
2. Open / Closed Principle
“Classes should be closed to change but open to development.”
While creating our classes or methods, we need to design by anticipating new requests and developments that may occur in the future. Therefore, creating a structure in which new requests can be added or deleted
3. Liskovs’s Substution Principle
Our main goal is to be able to use subclasses instead of their derived (superior) classes without making any changes in our code.
The derived class, that is, the subclasses, should be able to use all the features and methods of the main (superior) class in a way that shows the same function and to have new features of their own.
Interfaces and abstract classes can use for this principle.
4. Interface Segregation Principle
If the methods that are not really needed and used in the class are implemented through the interface, these codes will be dummy codes, so the interfaces should be separated and it should be prevented from containing non-functional methods in terms of classes.
For example we have an interface and two classes(A, B) which implements this interfaces. Now lets say we need to add one more responsibilty to A class. So we shouldnt add the signature same interface which using between A and B.
Because B class doens’t have to had this responsibility.
5. Dependency Inversion Principle
Shortly, top-level classes should use Interface implementations, not lower-level class implementations.
The top-level module should not know or be interested in how the bottom-level business works. As a top-level module, I say; I don’t care about how the x data comes from the bottom side, I do my work about the x data that comes to me and send it to the necessary places. But whether the x data came from a database, an API or read from a text file is none of my business. In any case, such requests should not affect me.
Should be like this :
