Clean code is not written by following a set of rules. You don’t become a software craftsman by learning a list of heuristics. Professionalism and craftsmanship come from values that drive disciplines.
Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
It's time to talk about SOLID, perhaps the highlight subject of our Advanced Software Development article series. If you've come this far by reading the series, it's fine. If you came directly to this article, I suggest you read the 0- Advanced Software Development article.
You all know that SOLID is the indispensable question of recruitment interviews today. SOLID is an acronym for the top five object-oriented design (OOD) principles first introduced by American software engineer and educator Robert C. Martin in his 2000 article Design Principles and Design Patterns.
If you're familiar with Object Oriented Programming, you've probably heard of SOLID principles already. Before explaining what SOLID is, I would like to touch on why it is needed.
The software industry is getting popular day by day. The time shows that it will become more and more popular. As the popularity increases, there is a serious increase in the number of people entering the sector. This is why the Codemvia Community was established. Because while the interest in the sector is constantly increasing, software experts who write high quality code do not increase with the same momentum.
Today, companies are growing and the world is becoming a global village. Naturally, software projects that serve all this wheel can become gigantic. It is getting harder to ensure sustainability in these growing projects. The number of people working on a project is increasing and terms such as Agile and DevOps are entering our lives. It is difficult for newcomers to adapt quickly to large projects written by large teams or to add new features to these projects.
Loosely Coupled, a software development principle put forward as a solution to this problem, provides a high level of benefit. Loosely Coupled a software development principle that allows modules of a system to be used or expanded separately from each other. This principle, which argues that a project should not be tightly bound to an object in order to work, has a very important place for the software development system. Although the Loosely Coupled principle is not included in the SOLID principles, it is an important underlying issue.
SOLID is an acronym consisting of the initials of 5 principles. Let's talk about these principles:
S — Single Responsibility Principle (SRP)
This principle says that a class, module or function should be only one area of responsibility. What we call Loosely Coupled should show itself here. Classes should be clearly separated from each other. Each class should be responsible for only one function of the program it is in and should cover this part. Robert C. Martin tell “A class must have only one reason to change”.
O — OCP (Open/Closed Principle)
Every class, module, or function should be open to development but closed to change. A module prepared according to this principle should be impervious to change of source code but should allow extension of its behavior.
L — LSP (Liskov's Substitution Principle)
This principle says that the subclasses of the classes can be used for the same function.
I — ISP (Interface Segregation Principle)
This principle, which means the separation of interfaces, tells that interfaces should not be too large, divided into smaller interfaces. In this way, each interface will only have the functions it will need and will not run unnecessary codes. Every job that can be separated from each other should be designed with different interfaces. While other principles are more about classes, this principle is more about interfaces.
D — DIP (Dependency Inversion Principle)
The dependency reversal principle recommends using abstract classes instead of concrete classes. Because if high-level classes become dependent on low-level classes, improvements to be made may require changes in more than one class, as it will affect the main class. If instead they are linked to abstract classes, the principle of Loose Dependency will be more adhered to.
I have tried to briefly explain the principles that the initials SOLID represent. Of course, SOLID is not such a simple thing. A series of articles should be written on each principle; has already been written. However, it should not be overlooked that all of the SOLID principles are related to Loosely Coupled.
Although the use of SOLID principles is not mandatory, it is clear that the use of it will increase the quality and prevent a serious loss of time in the expansion stages of large projects. Projects developed without complying with SOLID principles have a shorter lifespan. Because it will not be able to handle expansions that will be needed in the future. You can all guess that software is like a living living organism. It is not stationary. They need to be constantly improved. I think we agree that 10 years ago, if the best software is not developed, it will still not be the best software. That's why it will make our job easier to comply with SOLID principles in order to carry out a continuous renewal, development and expansion work more flexibly.
Of course, there are many principles when it comes to software development. Apart from the SOLID principles, I would like to talk about these three principles in one sentence too:
YAGNI (You Ain't Gonna Need It): The YAGNI principle recommends adding no extra functionality until you really need it.
DRY (Don't Repeat Yourself): The DRY principle, which says "Don't repeat yourself", recommends that functions that perform the same function in more than one class should not be written over and over again.
KISS (Keep It Simple Stupid): The KISS principle asks us to keep things as simple as possible. Like that everyone who sees can understand. Contrary to the view that complex works are professional, he argues that simple designs are thought of more intelligently.
We must pay attention to the principles of software development so that we can provide the features that large projects should have, which we can describe with simple, extensible, flexible, developable, updateable, readable, plain and many other similar terms.
In this article, I touched on why principles should be, rather than what they are. But don't stop here. Be sure to keep researching what they are and how they are applied. I'm thinking of writing a separate article about how these principles are applied in Swift. Regardless of the language or framework you use, you will definitely find sample applications on the internet.
Be sure to try and even make it a principle to abide by these principles. There is no doubt that you will see the benefits. They will make you a better developer.
In the Advanced Software Development series:
Previous article: "6- What is Agile Scrum methodology? What are the benefits to software development teams?".
Next article: "8- What is Git? Why should I use it? What is Github, Gitlab, Bitbucket used for?".
Don't forget to like if you think it's useful :)
Always get better...
Oldest comments (0)