Software Principles

SOLID, DRY, KISS, YAGNI

SOLD Design principles

SOLID principles was mentioned by Robert J. Martin (a.k.a Uncle Bob) in his paper dated 2000.

Uncle Bob is also the author of bestselling books Clean Code and Clean Architecture, and is one of the participants of the "Agile Alliance".

Single Responsibility Principle

Class do one thing, around the object, manage one data model, For example having Sending Email function in Books Class.

Purpose:

Increase maintainability
Increase Traceability

2. OCP: Open Closed Principle

Means: Class should be opened for extension, Closed to modifications, avoid touching the tested and reliable (mostly) production code if possible.

Achieving that was mentioned by implementing interface using different classes according to the behavior

Purpose :

increase the reliability, and prevent shutdown due to the code changes.

Drawbacks

This principle produce lot of refactoring requirements, as the solution will be scattered over punches of interfaces and classes, instead of operations, which not mentioned by the principles

3. Liskov substitution

As inheritance is Focusing on full implementation of the parent class, partial replaceability of the class is the main concern of LISKOV, using overriding for specific portion of the code.

For example: You need to implement the Area calculation in square class, while you are extending rectangle class.

Purpose :

Replaceability, valid with third parties and integration.

4. ISP: Interface segregation principle

Segregation means keeping things separated, and the Interface Segregation Principle is about separating the interfaces.

So if you have class that implements multiple functionalities, in different states, you can group functionalities together in according to it domain, by different interfaces , and each interface can implement only the correlated functionalities.

Example:

Shipment class operations:

Create Shipment, ConfirmShip, DeleShipment, CloseShipment, ArchiveShipment

Interfaces:

IOpenedShipments: Implement:

CreateShipment, ConfirmShipment, ConfirmShip, DeleteShip

IConfirmedShipment: Implement:

Implement only CloseShip,

IClosedShip : Implement:

Implement only ArchiveShip

Purpose: Reduce complexity, Enhance Maintainability

5. DIP: Dependency Inversion

The Dependency Inversion Principle (DIP) states that a high-level class must not depend upon a lower level class, both should depends on abstract classes/interfaces.

The Dependency Inversion principle states that our classes should depend upon interfaces or abstract classes instead of concrete classes and functions.

Uncle Bob summarizes this principle as follows:

"If the OCP states the goal of OO architecture, the DIP states the primary mechanism".

These two principles are indeed related and we have applied this pattern before while we were discussing the Open-Closed Principle.

We want our classes to be open to extension, so we have reorganized our dependencies to depend on interfaces instead of concrete classes.

Purpose

Increase the maintainability, Changeability

DRY Principle

DRY, which stands for 'don't repeat yourself,' is a principle of software development that aims at reducing the repetition of patterns and code duplication in favor of abstractions and avoiding redundancy

How to Achieve DRY

Divide your system into pieces according to its domain (DDD, SRP), by scanning all operation types: Security, Reporting, DB Layer and etc
Don't write lengthy methods, but divide logic and try to use the existing piece in your method.
Apply configurable solutions patterns (Comes from micro-services)
Go for extendable solutions, inherited from the organization vision and long term objectives, ass example, initial versions will connect to SQL server databases only, but the next versions will connect to oracle and MySQL.

DRY Benefits

Less code is good leads to time saving and effort
Increase maintainability
Reduces the chances of bugs
Increase reusability

KISS Principle: Keep It Simple, Stupid

The KISS principle is descriptive to keep the code simple and clear, making it easy to understand.

How to Achieve it:

so keep coding simple and straightforward. Keep your methods small. Each method should never be more than 40-50 lines.
Each method should only solve one small problem, not many use cases. If you have a lot of conditions in the method, break these out into smaller methods. It will not only be easier to read and maintain, but it can help find bugs a lot faster.
Decrease number of loops
Decrease number of branches for decision
Keep SRP applied

Benefit:

Increase maintainability index
Decrease cycolmatic index
Higher response to shutdown issues
Simplify Onboarding/handover process

YAGNI principle

YAGNI (You Aren't Gonna Need It - very New Yorkish sounding), which also frowns upon complexity, in particular the kind you introduce in order to solve a possible future problem that you don't have.

It's one of Extreme Programming (XP) practice.

One of the Agile principles is to increase the amount of work not to be done due.

Scope creeping: