Solid design principles
Download as PPTX, PDF
0 likes336 views
SOLID is a set of 5 design principles of Object Oriented Design in software engineering intended to make software development more- Flexible Easier to maintain Easier to understand.
Solid design principles
- 1. 1 SOLID Design Principles Md Shohag Mia eshohag@outlook.com
- 2. 2 SOLID- What does mean it? SOLID is a set of 5 design principles of Object Oriented Design in software engineering intended to make software development more- Flexible Easier to maintain Easier to understand
- 3. 3 What is SOLID? The SOLID principles of Object Oriented Design include these five principles: S Single Responsibility (SRP) O Open/Closed Principle (OCP) L Liskov Substitution Principle (LSP) I Interface Segregation Principle (ISP) D Dependency Inversion (DIP)
- 4. 4 Why we should care? Cleaner code Code smells are kept away Codebase that is maintainable, expandable & understandable Usually integrated in Agile methodologies, i.e. Scrum Loose coupling (DIP)
- 5. 55 Single Responsible Principle 5 A class should have only a single responsibility to carry & one reason to changes.
- 6. 6 Is it supported for single responsible principle?
- 8. 88 Open/Closed Principle 8 Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
- 9. 9 Code sample Added a new feature
- 10. 10 Code sample
- 11. 1111 Liskov Substitution Principle 11 Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. Example: If Child is a Subtype of Parent then objects of type Parent may be replaced with objects of type Child
- 12. 12 Code sample
- 13. 13 Code sample
- 14. 1414 Interface Segregation Principle 14 Clients should not be forced to depend upon interfaces that they do not use. Example: Our client are totally independent because if they are not able to take features. If needed in future than they can.
- 15. 15 Code sample
- 16. 1616 Dependency Inversion Principle 16 High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces). Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions. N.B: Implementation Business Logic Layer/Data Access Layer
- 17. 17 Code sample
- 18. 1818 Follow Me GitHub- https://github.com/eshohag/SOLID 際際滷Share- /MDShohagMia Linkedin- https://www.linkedin.com/in/eshohag/ Twitter- https://twitter.com/shohagds 18
- 19. 19 Q & A
- 20. 20 THANK YOU