S.O.L.I.D the 5 principles every programmer should know
S.O.L.I.D is a term for Robert C. Martin's first five object oriented design principles,These concepts seek to make software architectures more comprehensible, easier to manage and easier to extend.
every software engineer should know thees concepts.
S — Single Responsibility Principle
The Single Responsibility Principle states in programming that each module or class will have responsibility for a particular part of the software's functionality.
There is a famous quote: "Do one thing and do it right."
This is known as Single Responsibility Principle.
O — Open/closed principle
The open / closed theory states, in programming, that software entities (classes, modules, functions, etc.) should be open to extensions, but closed for modification.
anyone who understands Object Oriented Programming generally, probably already know about polymorphism. We can ensure that our code complies with the open / closed principle by using inheritance and/or implementing interfaces which allows.
L — Liskov substitution principle
This theory specifies that objects of a superclass are to be replaceable without breaking the program with objects of its subclasses. That allows your subclass objects to behave in the same way as your superclass objects do. You can accomplish this by following a few rules which are somewhat similar to the Bertrand Meyer specified contract model design.
I — Interface segregation principle
Throughout programming, the theory of interface segregation states that no client should be forced to rely on methods that he does not use.
To put it more simply: Do not add additional features by applying new methods to an existing interface.
Instead, build a new interface, and if appropriate allow your class to implement multiple interfaces.
D - Dependency inversion principle
In programming, the concept of dependency inversion is a way of decoupling software modules.
This concept states that modules of high level should not be reliant on modules of low level. Both should be made based on abstractions.
Abstractions are not to be based on data. Abstractions will depend on the data.
In order to comply with this theory, we have to use a design pattern known as an inversion pattern of dependency,
0 comments