What is SOLID?! — Bonus DRY principle

👋 Hi everyone, happy to see you in my article.

If you did not read my previous articles yet, then take a time and check them out. Believe me, you will regret if you don’t read them! 😊

• Important things that every iOS Developer should know + Book advise
• What is Reactive Programming | RxSwift + Bonus Books
• Async/await in Swift | What is it?!
• What is SwiftLint? — The trip to the Clean Code
• Grand Central Dispatch & DispatchQueue in Swift

Did you like my articles? If yes, then you can follow, clap and write a comment to show me your support. Now let’s start with the SOLID!

What is SOLID?

SOLID is a set of basic principles that every software developer should know. The aim of these principles, proposed by Robert C. Martin (If you checked my previous article, you saw my book advises from him) and abbreviated by Michael Feathers, is to develop maintainable, understandable, flexible and reusable software without code duplication.

SOLID principles are a set of rules that a software developer must follow when developing software with Object Oriented Programming (OOP) so that the software he develops is flexible and suitable for development. No matter how big our applications we develop in line with these principles, complexity is never an issue. These principles also enable us to write “Clean Code” instead of the complex codes we call “Spaghetti Code”.

These principles, which enable us to develop world-class software, can be discussed under 5 main headings.
1. S-Single Responsibility Principle
2. O-Open/Closed Principle
3. L-Liskov Substitution Principle
4. I-Interface Segregation Principle
5. D-Dependency Inversion Principle

Let’s take them one-by-one, and see what they tell us.

Just keep in mind that you need SOLID principles in your career even if you are a junior developer.

1. Single Responsibility Principle
   The purpose of this principle is to ensure that when an update or change is desired in the developed project, the desired change can be made by simply going to the relevant method without getting lost in the code. To explain a little more; instead of giving a function more than one job and holding it responsible for many jobs, we should create a separate method for each job and when a change is made in the future, we should be able to easily go to the relevant method and make the necessary changes.
2. Open/Closed Principle
   The principle states that the objects developed in the project should be open to development but closed to change. That is, an object should be able to gain new features without changing its behavior. This principle is the basis for writing code that is maintainable and reusable.
3. Liskov Substitution Principle
   Simple to say: Classes that are derived by inheriting must first use all the properties of the object they inherit, and then contain their own properties. If the class we create does not use ‘all’ properties of the object it inherits from, we end up with unnecessary code blocks and this is the last thing a developer wants. Because a developer always tries to write ‘Clean Code’.
4. Interface Segregation Principle
   Instead of adding more responsibilities to an interface than necessary, multiple more specialized interfaces should be created. Objects should not be forced to inherit interfaces that contain features or methods they do not need. As you may have noticed, the principles of “Single Responsibility” and “Interface Segregation” are very similar and serve the same purpose. However, the most important point that should not be overlooked here is that the ‘Interface Segregation’ principle deals with interfaces, while the ‘Single Responsibility’ principle deals with classes.
5. Dependency Inversion Principle
   According to this principle, changes made in lower classes should not affect upper classes, that is, dependencies between classes should be as low as possible and especially upper level classes should not depend on lower level classes. So what should we do here? We should create a layer of abstraction between the high level class and the low level class and manage both classes through abstract concepts.

SOLID is fear of most junior developers. But as you can see it is really easy to learn and implement. Whatever you work on, try to implement SOLID principles, you will see the result immediately. You will like your codes and other developers also will like your codes because it will be much easier to understand.

As I promised in the title, here are the 2 bonus principles.

1. DRY Principle
   Dont Repeat Yourself — it tells you what to do with its name. Just do not repeat yourself when you are coding. Repeating yourself looks very funny. Take coding as talking or writing an essay. Would you mention in your essay “Bus” or “Plane” twice right after? Of course, you wouldn’t. Then why should you do it in your code?
   Let me explain what I mean with an example. Would you rather prefer following version:

Code that DRY is not implemented

or would you prefer this:

Code that DRY is implemented

I hope that it was quite good explanation. But keep in mind that making your code too much DRY is also not good.

Basically that is all from my side. If you like my articles, if you think that they are useful, you can click on “Follow” button and share articles to reach more people. :)