Principles

• S.O.L.I.D
• Approaching the Solution
• Implementing the Solution

What is S.O.L.I.D?

SOLID principle is a coding standard that all developers should have a clear concept for developing software in a proper way to avoid bad design. This was promoted by Robert C Martin and is used across the object-oriented design scope. It makes your code more extendable, logical and easier to read.

 

• Single responsibility
• Open-close
• Liskov substitution
• Interface segregation
• Dependency inversion

Single responsibility

A class should have one, and only one, reason change.

One class should only serve one purpose and they should all relate directly to the responsibility of the class. All the methods and properties should all work towards the same goal.

A class should be modified as soon its responsibilities changes.

It makes your software easier to implement and prevents unexpected side-effects of future changes.

Open-close

Entities should be open for extension, but closed for modification.

Software entities be extendable without actually changing the contents of the class we are extending.It is possible to modify the behavior of our code without touching a piece of original code.

Liskov substitution 

The Liskov substitution principle was introduced by Barbara Liskov in her conference keynote "Data abstraction" in 1987.

Objects of a superclass shall be replaceable with objects of its subclasses.

Requires the objects of subclass to behave in the same way as the objects of its superclass.

Interface segregation

A client should not be forced to implement an interface that it doesn't use.

This rule means that we should break our interfaces in many smaller ones, so they better satisfy the exact needs of our clients.

Similar to the Single Responsibility Principle, the goal of the Interface segregation principle is to minimize the side consequences and repetition by dividing the software into multiple, independent parts.

Dependency inversion

Depend on Abstractions not on concretions.

High-level modules should not depend on low-level modules.

Both should depend on abstractions.

Abstractions should not depend on details. Details should depend on abstractions.

By applying the Dependency inversion the modules can be easily changed by other modules just changing the dependency module.

Approaching the solution

KISS

Keep it Simple and Stupid.

A simple solution is better than a complex one. Even if the solution looks stupid.

Can be used in variety of disciplines, such as interface design, product design, and software  development.

Implementing the solution

YAGNI

You aren't gonna need it.

Do write code that is no use in present while guessing that will come in handy in the future. But requirements always change. This is a waste of time. Write the code you need for the moments only.

DRY

Don't repeat yourself.

Duplication in logic should be eliminated via abstraction.

Duplication in process should be eliminated via automation.

Always rescue code you write.

Keep code generalized and reusable.

DRITW 

Don't reinvent the wheel.

Don't need to design a solution.

Don't need to design a solution from nothing when a solution already exits. Someone else might have already solved the same problem. Make use of that.

Kaizen

Leave it better than you found it.

Create a culture of continuous improvement where all employees are actively engaged in improving the company.

Don't focus to only fix the bug but the code around it.

Constantly ask team members to evaluate their own work and to help review the work of their peers.

By reviewing the work, team tend to detect errors and shortcomings at the right time.