Who knows Solid Principals ?? anybody knows / nobody knows !!
In software engineer life, SOLID is a common word frequently heard. Some people know it exactly, and some have partial knowledge. So here I am going to explain SOLID in a way that I understand.
Before going to SOLID why we need it ?
Let's start with "S"
Single Responsibility Principle (SRP)
"Class have only a single responsibility or job" yes very simple. one class has one responsibility. that it. take look at this example
in here the invoice class had too many task's add invoice/ delete invoice are relevant tasks but sending email/ Error longing is not suitable in here. so this is example of single responsibility violation.
after apply the single responsibility it should be like this
Then we go for the "O"
Open/Closed Principle(OCP)
"Class should be open for extension but closed for modification" (did you understand this ?? nope right :-)
“Don’t implement new functionality in existing method” (dam yeps) that its.
when require the new change in the existing code it will affect the reference that is already used so the better pastries is to implement it as new extension
here is the example;
Before OCP
in here the new invoice type "Recurring invoice" is introduce and need the change the invoice calculation module. so the changes will affected the already reference modules and it will cause the error.
After OCP
used the magical "Override" keyword, now everybody is happy
Then the "L"
Liskov Substitution Principle(LSP)
dont panic Babara Liskov that's why Liskov comes
"Objects of a super class shall be replaceable with objects of its subclasses without breaking the application"
little complicated but simply able to implement the supper class functionalities in sub class without breaking the hierarchy.
go thought this example
Before LSP
After LSP
Now go for "I"
Interface Segregation Principle(ISP)
Many requirement-specific interfaces are better than one general-purpose fat interface
the common issue here is "not implemented exceptions"
Before ISP
After ISP
Finally the "D"
Dependency Inversion Principle(DIP)
"High-level Classes should not direct reference on low-level classes"
keep loose coupling instead of tight cupping in between the high level class and and the low level class improve the deployment independence. please look at the following samples.
Before DIP
After DIP
that's All ...
