SOLID Principles — OOP Design Principles
Entered into our lives by Michael Feathers in the early 2000’s, S.O.L.I.D. The principles of Object-oriented programming are accepted as the basic principles of software development that every developer who develops OOP should know. It was compiled as “first five principles of object-oriented programming and design” by Robert C. Martin and named it SOLID.
SOLID principles; It is the set of approaches and principles that ensure that the developed software is understandable and more readable, improvable and reusable, sustainable and flexible, and prevents code repetition. More simply;
They are approaches that enable writing code in structure and architecture that are open to changes that will be required in the future for the developed project and can keep up with these changes with minimum effort.
The main objectives of the principles defined by Michael Feathers are as follows:
· The developed software can be easily adapted to the requirements that will arise in the future,
· Easily add new features without the need for a change in the code
· Providing the least change on the code against new requirements,
· Minimizing the time loss caused by problems such as continuous correction and rewriting on the code.
While the software developed by applying these principles grows, we prevent the growth of complexity. In order to write clean code, it is necessary to adopt software development in accordance with these principles. So that we can eliminate or easily overcome the main problems we have experienced during the development process.
What are the main problems encountered during this development phase:
· Rigidity: The design used cannot be improved and no additions can be made.
· Fragility: A change made in one place causes trouble in another.
· Stability: An improved module is not reusable elsewhere. (Reusable)
· Cost : development costs and times increase
What are the SOLID Principles :
S — Single Responsibility Principle ( SRP ) :
Each class or method should have a single responsibility and function. So a class or method’s area of responsibility should only have one job to do, and its content should only be about its own responsibility. Otherwise, garbage codes that we call spaghetti code, which are not understood and which are very costly to change and develop, emerge.
For example:
Methods that carry out Logging operations should not be placed in a class that performs database operations. Logging methods must be in the Logger class and used through the object of this class.
Or another example; there should not be a method that checks the mail address validation in the class with Login operations. It must be in a separate class and used through the object of this class.
O — Open-Closed Principle ( OCP ) :
A class or method should keep its existing basic properties and not allow changes to them. It should be able to acquire new features without changing its current behavior.
Shortly mean, being open to new features and development, and being closed to feature loss and change.
L — Liskov Substitution Principle ( LSP ) :
It was first introduced in 1988 by MIT professor Barbara Liskov in his book Abstraction and Hierarchy. In a very difficult way to understand J
“Let all programs (functions) that take parameters in terms of T be P, be an o1 object of S type and an o2 object of T type. If the behavior of P does not change when o1 and o2 objects are replaced, type S is a subtype of type T! “
Subclasses must use all the features of the super class from which they derive. Objects created in subclasses have to behave the same when they are replaced by objects of the superclasses, without the unused feature.
For example :
A square is a rectangle and it derives from the Rectangle class. Thus, the Square class can act as the Rectangle class wherever desired.
However, changing the height and width parameters of the Square and Rectangle classes will cause different behaviors and in this case the Square class cannot replace the Rectangle class. In such a case, for example, the area calculation method will not be accurate for the Square class.
In this case; By creating an interface named Shape, we must implement the Square and Rectangle classes from the Shape interface. CalculateArea method should be included in the Shape interface.
In this way, we can correctly customized the area calculation process for the Square and Rectangle classes that implement the Shape interface and the CalculateArea method in it.
I — Interface segregation principle : ISP ( Özelleşmiş Kontrat/Arayüz Ayrımı prensibi ) :
When an interface is implemented into a class, class must implement and create the methods that the interface contains. Created and unused methods thats implemented will result in dysfunctional and dummy codes.
For this reason, unused and unnecessary methods and features should not be added to the interface, and responsibilities should be separated by writing more than one customized interfaces.
For example:
Let’s assume that there is an interface named Animal and it contains the methods of eat (), fly (), bark (). In this case, the Dog class that implements the Animal interface will have implemented the fly () method unnecessarily. Likewise, the Bird class, which implements the Animal interface, will use the bark () method unnecessarily. For this example; If we define the fly () method in the Flyable interface, the bark () method in the Barkable interface, and implement the relevant interfaces to the classes, we will obtain a more customized and separated structure. If the Dog class implements the Barkable interface, which includes the bark () method, it will not have the fly () method unnecessary.
D — Dependency Inversion Principle ( DIP ) :
Inter-class dependencies should be as little as possible. In layered architectures, upper level modules should not be directly dependent on lower level modules. Instead of a class being directly dependent on another class, the link between them should be provided through abstract concepts. This abstract concept can be an interface or an abstract class.
For example:
Let’s write a method that outputs Studentds table as xml. Writing the export process by making xml conversion in a method in the relevant class will not be a good forward-looking method. Because just xml export process may be required now , but after a while, export in json, csv, txt, html etc. formats can be requested. In this case, we need to take the exporting method into an interface like an IDataExporter and implement this interface to the relevant classes. When export data in a different format is required, it will be updated in a cost-free and practical way by updating only the method in the IDataExporter interface according to the desired parameter.
To be a good software developer, SOLID principles must be learned and applied. When adding new functions to the developed code or making error corrections, the compliance of the code with the principles of SOLID must be increased with refactoring practices and SOLID information.
In addition to SOLID, there are more structure such as Kiss, Yangi, Dry, Reuse Release Equivalence, Common Closure principles.
Kiss ( Keep it Simple Stupid / Keep It Short and Simple ) :
It was first expressed in the American Navy in the 1960s. While solving a problem, we should develop an application by choosing the simplest, plain and understandable solution method possible. We can say that it is similar to the “Less is More” movement, which is the basis of the minimalist approach.
Of course, Einstein said something about it: “Everything should be made as simple as possible, but no simpler.”
Yangi ( You Aren’t Gonna Need It! ) :
It is the software development policy that states that no functionality should be added until it is deemed necessary and used. In other words, we should not include the codes we do not need at the moment, we should not make any additional improvements by predicting about the features that can be added in the future. We should remove unused codes saying I don’t need it.
Dry ( Don’t Repeat Yourself ) :
It is a software development principle that aims to prevent code duplication and the redundancy / confusion that may arise in the project. It is necessary to develop an approach that will centralize repetitive codes by singularization.
The DRY principle emphasizes that “every information must exist in a single, precise and authorized representation in a system”. The principle was formulated by Andy Hunt and Dave Thomas in the book Pragmatic Programmer2.
Reuse ( Release Equivalence Principle ) :
It is necessary to establish reusable structures in order to manage the dependencies between the packages / namespaces used in the system.
Common Closure Principle : It is the adapted version of Single Responsibility for packages / namespaces. Classes that may change due to the same reason should be under the same namespace. In this way, it is aimed to prevent changes that may occur in the system from affecting the entire system.
