As previous, we discussed two property S-Single Responsibility Principle, O-Open Closed Principle.
Rest three property is -
L-Liskov’s Substitution Principle.
I-Interface Segregation Principle.
D-Dependency Inversion Principle.
L-Liskov’s Substitution Principle-"Derived writes must be completely substitutable for their base kind."
It implies that the classes kindred developer made by extending your class ought to have the capacity to fit in the application without fail. i.e. in the event that a kindred developer poorly extended some piece of your class and injected into system/application then it ought not to break the application or ought not to toss lethal special cases.
This can be guaranteed by utilizing strictly following the main rule. On the off chance that your base class is completing one thing strictly, the kindred developer will abrogate just a single element erroneously in the worst case. This can cause a few mistakes in a single territory, yet the entire application won't do down.
I-Interface Segregation Principle-"Clients should not be compelled to execute pointless techniques which they won't utilize."
Take a case. Designer Alex made an interface Reportable and included two methods getGenerateExcel() and getGeneratedPdf(). Presently customer 'A' needs to utilize this interface, however, the means to utilize reports just in PDF design and not in exceeding expectations. Will he achieve the functionality easily?
NO. He should implement two methods, out of which one is the additional weight put on him by the designer of software. It is possible that he will implement another technique or leave it blank. So are not wanted cases, right?
So what is the arrangement? An answer is to make two interfaces by breaking the current one. They should be like PdfReport and ExcelReport. This will give the adaptability to the client to utilize just required functionality as it were.
D-Dependency Inversion Principle- "Rely upon abstractions, not on concretions."
As such. you should design your software such that different modules can be isolated from each other by utilizing an abstract layer to tie them together.
The established utilization of this rule of BeanFactory in spring structure.
In the spring system, all modules are given as independent components which can cooperate by just infused dependencies in different modules. They are so very much shut in their boundaries that you can utilize them in other software modules separated from spring without breaking a sweat.
This has been accomplished by dependency inversion and open shut standards.All modules uncover the main abstraction which is valuable in broadening the functionality or module in another module.
About Author
Avaneesh Kumar Verma
Avaneesh is a Software developer Having Knowledge Java , J2EE ,Data Structure and Algorithm ,SQL.