SOLID Desing Principles
(S) : Single Responsibility Principle:
A class should be responsible for one thing, for example, if a person class responsible for holding the property of a person and methods, it shouldn’t be responsible for communicating the file system for persistency or database migrating operations. There should be separated classes for other responsibilities.
(O): Open Close Principle:
The open-close principle states that a class should be extendible and open to extending easily but that should be closed for modification. So you should extend the behavior without changing the class itself. But how can you do this, the answer is inheritance and interfaces, you can simply extend the class or implements the interfaces. Because the class could be already sent to the customer and we don’t want to change the sent/published classes.
(L): Liskov Subsution Principle:
The idea is you should be able to substitute a base type for a subtype. For this, we need to define a method that will be overridden as virtual and we define the overriding method with the override keyword.
So compiler will look up subtype method in symbol tables instead of the parent method..
(I): Interface Segration Principle:
We need to keep simple as much as possible our interfaces. So developers who implement our interfaces will not have to implement the methods they actually do not need. We need to keep simple and atomic our interfaces make sure people do not pay for what they actually do not need. So the basic idea, if you have too much stuff in one interface, simply divide it into smaller pieces of interfaces.
(D): Dependency Inversion Principle:
The idea is , the high level of the system should not directly depend on some low-level system parts.
Instead, they should depend some kind of abstraction. For example, we implement an API that query on some sort of data. If we expose this data to this API, we create a dependency on that type of data and way of storing it on High-Level API. Instead of this bad approach, we can use a sort of Abstraction to reach the data. So even way of storing it changes in the future, we are not aware of and especially don’t care about this changed way of storing data.
We will go further with design patterns in series of this posts.
Here are the brief list of which design pattern will be discussed.
