27 September 2021

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.

Leave a Reply

Your email address will not be published. Required fields are marked *