The S.O.L.I.D Principles in Pictures
© Ugonna Thelma
© Ugonna Thelma
S — Single Responsibility
A class should have a single responsibility
Goal
This principle aims to separate behaviours so that if bugs arise as a result of your change, it won’t affect other unrelated behaviours.
A class should have a single responsibility
Goal
This principle aims to separate behaviours so that if bugs arise as a result of your change, it won’t affect other unrelated behaviours.
O — Open-Closed
Classes should be open for extension, but closed for modification
Goal
This principle aims to extend a Class’s behaviour without changing the existing behaviour of that Class. This is to avoid causing bugs wherever the Class is being used.
Classes should be open for extension, but closed for modification
Goal
This principle aims to extend a Class’s behaviour without changing the existing behaviour of that Class. This is to avoid causing bugs wherever the Class is being used.
L — Liskov Substitution
If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program.
If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program.
Goal
This principle aims to enforce consistency so that the parent Class or its child Class can be used in the same way without any errors.
This principle aims to enforce consistency so that the parent Class or its child Class can be used in the same way without any errors.
I — Interface Segregation
Clients should not be forced to depend on methods that they do not use.
Goal
This principle aims at splitting a set of actions into smaller sets so that a Class executes ONLY the set of actions it requires.
Clients should not be forced to depend on methods that they do not use.
Goal
This principle aims at splitting a set of actions into smaller sets so that a Class executes ONLY the set of actions it requires.
D — Dependency Inversion
- High-level modules should not depend on low-level modules. Both should depend on the abstraction.
- Abstractions should not depend on details. Details should depend on abstractions.
- High-level modules should not depend on low-level modules. Both should depend on the abstraction.
- Abstractions should not depend on details. Details should depend on abstractions.
Firstly, let’s define the terms used here more simply
High-level Module(or Class): Class that executes an action with a tool.
Low-level Module (or Class): The tool that is needed to execute the action
Abstraction: Represents an interface that connects the two Classes.
High-level Module(or Class): Class that executes an action with a tool.
Low-level Module (or Class): The tool that is needed to execute the action
Abstraction: Represents an interface that connects the two Classes.
Details: How the tool works
This principle says a Class should not be fused with the tool it uses to execute an action. Rather, it should be fused to the interface that will allow the tool to connect to the Class.
This principle says a Class should not be fused with the tool it uses to execute an action. Rather, it should be fused to the interface that will allow the tool to connect to the Class.
It also says that both the Class and the interface should not know how the tool works. However, the tool needs to meet the specification of the interface.
Goal
This principle aims at reducing the dependency of a high-level Class on the low-level Class by introducing an interface.
Goal
This principle aims at reducing the dependency of a high-level Class on the low-level Class by introducing an interface.
Firstly, let’s define the terms used here more simply
High-level Module(or Class): Class that executes an action with a tool.
Low-level Module (or Class): The tool that is needed to execute the action
Abstraction: Represents an interface that connects the two Classes.
High-level Module(or Class): Class that executes an action with a tool.
Low-level Module (or Class): The tool that is needed to execute the action
Abstraction: Represents an interface that connects the two Classes.
Details: How the tool works
This principle says a Class should not be fused with the tool it uses to execute an action. Rather, it should be fused to the interface that will allow the tool to connect to the Class.
This principle says a Class should not be fused with the tool it uses to execute an action. Rather, it should be fused to the interface that will allow the tool to connect to the Class.
It also says that both the Class and the interface should not know how the tool works. However, the tool needs to meet the specification of the interface.
Goal
This principle aims at reducing the dependency of a high-level Class on the low-level Class by introducing an interface.
Goal
This principle aims at reducing the dependency of a high-level Class on the low-level Class by introducing an interface.
Full article:
medium.com/backticks-tild…
medium.com/backticks-tild…
#solid #solidprinciple
@UnrollHelper
• • •
Missing some Tweet in this thread? You can try to
force a refresh
