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.
- 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.