SOLID Principle

SOLID Principle definition

• SOLID Principle is a coding principle.
• SOLID is Object Oriented Design
• S.O.L.I.D is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin, popularly known as Uncle Bob, it includes the following principles :
  • Single responsibility principle,
  • Open-closed principle,
  • Liskov substitution principle,
  • Interface segregation principle,
  • and Dependency inversion principle.

SOLID Principle purpose

• These principles, when combined together, make it easy for a programmer to develop software that is easy to test, maintain, and extend.
• They also make it easy for developers to avoid code smells, easily refactor code, and are also a part of the agile or adaptive software development.

SOLID Principle benefits

• SOLID principles help software developers to achieve scalability and avoid that your code breaks every time you face a change.

SOLID acronym

• S : Single-Responsibility Principle
• O : Open-Closed Principle
• L : Liskov Substitution Principle
• I : Interface Segregation Principle
• D : Dependency Inversion Principle

S : Single-Responsibility Principle

• This principle states that an object/class should only have one responsibility and that it should be completely encapsulated by the class.

Single Responsibility Principle practice

• The Single Responsibility Principle says to separate the code that different actors depend on.
  • Also, gather together the things that change for the same reasons.
  • Separate those things that change for different reasons.
  • To sum up, a class should have one and only one reason to change, meaning that a class should have only one job.

O : Open-Closed Principle

• This Principle affirms that an entity allows its behavior to be extended but never by modifying its source code.
  • Any class (or whatever you write) should be written in such a way that it can be used as is.
  • It can be extended if need be, but it can never be modified.
  • Objects or entities should be open for extension but closed for modification.

L : Liskov Substitution Principle

• This Principle confirms that objects should be replaceable by instances of their subtypes without affecting the functioning of your system from a client’s point of view.
  • Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

I : Interface Segregation Principle

• This Principle States that once an interface is becoming too large/fat, we absolutely need to split it into small interfaces that are more specific.
  • A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use

D : Dependency Inversion Principle

• This principle is primarily concerned with reducing dependencies amongst the code modules.
  • Entities must depend on abstractions, not on concretions.
  • It states that the high-level module must not depend on the low-level module, but it should depend on abstractions.

More informations for Scrum Testing

More informations for the Scrum PSD certification here.