Programming Principles(YAGNI, SOLID, KISS, DRY, Delegation)

Programming Principles should be known by every programmer

Programming principles should be taken into account when the project is written, so that changes made in any part of the project (module/class/file/method…) do not cause serious problems to other parts.

When something is changed later in the specification or new functionality is optionally added, the update in the part of our system that has changed should have minimal impact on other parts.

I am gonna try to explain the logic of the following concepts without writing any code in this article.

1. YAGNI
2. KISS
3. SOLID
4. DRY
5. Delegate

Let’s start…

YAGNI: You Are’t Gonna Need It

We often don’t delete the code we wrote but don’t use now. Because it might be needed in the future.

The main purpose of this principle is that during refactoring, we should not hesitate to delete any old piece of code (method/class/file/some logic) if we do not need it.

In fact, this principle requires a bit of Foresight.

Because one of the main goals is that when writing a piece of code, we should consider whether it will be needed in the future, not just because it is needed now.

Don’t be afraid to remove the code :) At worst you will be able to revert from the git repo.

KISS: Keep It Simple, Stupid (with other hand Keep It Super Simple)

Albert Einstein said: “If you can’t explain something to a six year old, you don’t understand it well enough.”

The main goal here is to write the code as simple as possible and in such a way that even the most junior person can understand it.

Although it sounds a bit strange, you should think of the person who will read the code as the stupidest person and write it in the simplest way.

The purpose of software engineering is to reduce complexity, not to create it. -Pamela Zave

SOLID: stands for five principles

The main goal is to write understandable, maintainable and extensible code.

These principles should be applied after the project has passed the prototype stage. There is no such thing as always having to be applied everywhere, but if it is to be applied, it is considered better to fulfill all the principles as much as possible.

It consists of the following 5 main principles.

S) Single Responsibility Principle

Each method or class should have only one responsibility. One class should not do the work of another.

Otherwise, when we make a change in a method that is not written according to this rule, we have to review that change one by one wherever it is used.

Writing code like small parts and serving one purpose makes the code resuable and easier to understand.

It is one of the most important principles to overcome spaghetti code.

O) Open-Closed Principle

Software entities should be open for extension but closed for modification.

1. Open for extension, meaning that the class’s behavior can be extended; and
2. Closed for modification, meaning that the source code is set and cannot be changed.

Interface and Abstract classes are usually used to facilitate this process.

L) Liskov Substitution Principle

The principle defines that objects of a superclass shall be replaceable with objects of its subclasses without breaking the application.

The essence of this principle is that each child class should be able to replace its parent class without any problem (error).

It is one of the principles that is not easy to apply.

I) Interface Segregation Principle

Its main purpose is to prevent each class from having access to more than it needs. This makes the code easier to understand.

It should not be forgotten that when an interface is implemented, all the methods in it are necessarily overridden by the implementing classes.

That is, if we implement an interface with 5 methods and use only one of the overridden methods, there is a problem here. Because we have overridden the remaining 4 unused methods in vain.

In order to prevent such cases, we should divide the interfaces into the smallest possible interfaces so that the class implementing any of those interfaces uses all the methods it overrides.

D) Dependency Inversion Principle

Dependency Inversion principle means that developers should “depend on abstractions, not on concretions.”

Classes should depend on abstractions , not concretes .

Its main purpose is to weaken direct communication between closely related modules by using Interfaces and Abstract classes.

It is necessary to reduce the dependency between the components that need each other as much as possible. They should know minimal things about each other.

It helps to manage everything from one central system.

DRY: Don’t Repeat Yourself

SSOT (Single source of truth) — According to this principle, everything should have only one source.

That is, a logic should only be in one place, and everyone should take it from that place and use it.

Otherwise, it leads to code duplication, which causes a great loss of time when a new feature is added to the tree or when a new developer comes to the team to understand the code.

Delegation

Don’t do all stuff by yourself, delegate it to the respective class.

It is recommended to use in the following cases:

1. If we want to reduce the number of methods in a class
2. If we have multiple components doing the same thing

The goal is to delegate all the features to different classes and write each feature in one place so that it is resizable instead of gathering all the features in one class.

We can say that it is a kind of alternative to Inheritance .

Thanks for your attention…