SOLID Principles
In this article, I will talk about the solid principles that save the future of software, not today. In order to understand the SOLID principles, it is necessary to know the object oriented principles first. If you wish, you can read my article about object oriented principles from this link.
SOLID principles are the first letters of the five basic principles put forward by Michael Feathers in 2004, which ensure that the written code is understandable, clean and maintainable. The design patterns that left their mark on the 2000s include SOLID principles.
These principles are:
- Single Responsibility
- Open Closed
- Liskov Substitution
- Interface Segregation
- Dependency Inversion
Single Responsibility Principle:
In business life, instead of one person fulfilling all the responsibilities, there is a need for personnel specialized in a single responsibility. Similarly, in software development processes, classes and methods need a single responsibility to avoid complexity and obscurity. If a function has more than one responsibility, that method will be long and unintelligible. If a class has multiple responsibilities, that class can be complex and unmaintainable. For these reasons, each class and each function should have a single responsibility.
You see the worker class above. The CalculateRaise and IsPromotion methods are methods associated with the Worker class. However, the LogWork method is not associated with the worker. LogWork method needs to be in different classes.
The code block above is an example of a function-based use contrary to the single responsibility principle. In the same method, there are codes for calculating promotion, calculating the amount of raise, and sending e-mail to the promoted person. Instead of this usage, each operation above should be done in separate methods.
Open Closed Principle
The open closed principle is that the developed codes are closed to change and open to extension by adding new subclasses. According to this principle, the written codes should not be changed as much as possible, and new features should be added by adding new classes. Design patterns such as strategy and command are used to write code in accordance with the open closed principle.
In the above example, the CalculateRaise method calculates the raise amount for different departments. If there is a need to calculate raise for a new department, this code block will change. This contradicts the open closed principle.
As seen in the examples above, the SetRaiseRate method is implemented in subclasses to set the raise rate, and in the base class, the Raise Amount is calculated by using RaiseRate in the calculateRaise method. Thus, when a new department for which a raise is to be calculated is created, only that subclass will implement the raise rate, and the main code will not be changed. This structure conforms to the open closed principle.
Liskov Substitution Principle
According to the Liskov Substitution principle, a class must have all the properties of its superclass from which it inherits. For these reasons, this example does not comply with the liskov substitution principle. Example 4 comply the liskov substitution principle. As seen in that example, the properties( name, salary) and methods(calculateRaise) in the worker class are used in both salesman and engineer classes.
In the example above, the SetSalesGoal method is only suitable for salesmen. However, the Engineer class also derives from this class and has nothing to do with the SetSalesGoal method of the Engineer class. This is not in accordance with the Liskov Substitution principle. The solution of this principle for this problem is to create different interfaces for features belonging to only one group.
In the above example, a different interface was created for SalesGoal, and the Salesman class was inherited from it. The SetSalesGoal method has been removed from the Worker class. In this way, the Liskov Substitution principle is complied with.
Interface Segregation Principle
According to the interface segregation principle, interfaces should be separated according to clients in such a way that there are no idle features.
In the above example, the DBLogger and FileLogger classes are derived from the ILog interface. The methods needed in these classes are defined in ILog. However, although the CheckFileSize and GenerateFileName methods are not needed in the DBLogger class, they have to be used. Likewise, although there is no need for OpenConnection and CloseConnection methods in the FileLogger class, they have to be implemented. According to the Interface Segregation principle, these clients should be separated using different interfaces.
As you can see above, since the methods required by the client are different, the interfaces are divided into IDBLogger and IFileLogger accordingly.
Dependency Inversion Principles
According to the dependency inversion principle, the upper layers should not be dependent on the lower layers. An abstraction layer must be put in between.
References:
