A DRY KISS and a SOLID base with YAGNI

Empirical evidence shows there is no situation in which cluttered code won’t cause problems when it is further extended. That’s why Robert Martin created a set of rules for writing good code. They allows us to create simple, easily modified software.

Those SOLID principles many talk about are really helpful. We can really have messy code which does the same thing as the clean one. Except when you aim for long term healthy business. Solid code makes solid business. This acronym was coined later by Michael Feathers. The broad goal of the SOLID principles is to reduce dependencies so engineers modification one area of software while not impacting others. Additionally, they’re intended to create designs easier to grasp, maintain, and extend. Ultimately, using these design principles makes it easier for code engineers to avoid problems and to build adaptive , effective, and agile software.

Following the principles generally leads to writing longer and more complex code. However this and effort is well worth it because it makes software so much easier to maintain, test and extend.

S — Single Responsibility Principle.

O — Open-Closed Principle.

L — Liskov Substitution Principle.

I — Interface Segregation Principle.

D — Dependency Inversion Principle.

In the current environment, all developers should know and utilize these principles.

Single Responsibility Principle.

Each class should strive towards only one functionality. If we change the code, we should have a good reason, then we should know where is that single point where that reason applies. one responsibility equals one and only one reason to change.

Benefits.

· The class is easier to understand.

When the class only does “one thing”, its interface usually has a small number of methods that are fairly self-explanatory. It should also have a small number of member variables.

· The class is easier to maintain

Changes are isolated, reducing the chance of breaking other unrelated areas of the software. As programming errors are inversely proportional to complexity, being easier to understand makes the code less prone to bugs.

· The class is more reusable.

If a class has multiple responsibilities, and only one of those is needed in another area of the software, then the other unnecessary responsibilities hinder reusability. Having a single responsibility means the class should be reusable without modification.

Open-Closed Principle.

The idea of this principle is that existing, well-tested classes will need to be modified when something needs to be added. We know changing classes can lead to problems or bugs. Instead of changing the class, we can simply extend it. That’s why Martin summarizes this principle, “You should be able to extend a class’s behaviour without modifying it.”

Benefits.

· Extensibility

When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with ‘bad’ design. The program becomes fragile, rigid, unpredictable, and unreusable. This principle says that you should design modules that never change. When requirements change, you extend the behaviour of such modules by adding new code, not by changing old code that already that already works.

· Maintainability

When we talk about this benefit, an interface introduces an additional level of abstraction which enables loose coupling. The implementations of an interface are independent of each other and do not need to share any code. Also, you can easily cope-up with client’s keep changing requirements. Very useful in agile methodologies.

· Flexibility

In the case of plugins, you have a base or core module that can be plugged with new features and functionality through a common gateway interface. A good example of this is web browser extensions. Binary compatibility will also be in-tact in subsequent releases.

Liskov Substitution Principle.

The principle is named for Barbara Liskov, who introduced this concept of bahavioral subtyping in 1987. This principle says that every subclass or derived class should be substitutable for their base or parent class.

Benefits.

It is about many objects which can be easily replaced by objects of the same nature. New features around an existing one and changes are subjects of this principles. Integrate new objects fast.

Interface Segregation Principle

This one is simple. It basically is the reverse of the LISKOV: split your interfaces — meaning the desired functionality of your code — into pieces that are fully used.

Benefits.

· In real world projects, we often come up with an interface with multiple methods, which is perfectly normal as long as those methods are highly related to each other. Therefore, we make sure that our class needs all these actions to complete its task.

· Increases the readability.

· Increases the maintainability.

Dependency Inversion Principle.

High level modules should not depend upon low level modules. Both should depend on abstractions. Further abstractions should not depend on details. Detail should depend upon abstractions.

Benefits

· Loose coupling.

· Easier testing.

· Better layering.

· Interface-based design.

· Dynamic proxies.

KISS principle

KISS, an acronym for keep it simple, stupid, is a design principle noted by the U.S. Navy in 1960. The KISS principle states that most systems work best if they are kept simple rather than made complicated, therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.

YAGNI principle

“You aren’t gonna need it” , is a principle of extreme programming that states a programmer should not add functionality until deemed necessary. Ron Jeffries has written: “Always implement things when you actually need them, never when you just foresee that you need them”.

DRY

“Don’t Repeat Yourself” — every piece of knowledge must have a single, unambiguous, authoritative representation within a system.