Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SOLID principles-Present


Published on

  • Be the first to comment

SOLID principles-Present

  1. 1. OO Design: S.O.L.I.D principles Technical team DNB 2015 Page 1Confidential Presenters: Quang Nguyen, Lan Nguyen
  2. 2. Page 2Confidential Outline SOLID principles introduction Purpose of use. Definition, explanation, examples and benefits of + Single responsibility principle (SRP) + Open – close Principle (OCP) + Linkov's substitution principle (LSP) + Interface segregation principle (ISP) + Dependency inversion principle (DIP) Conclusion Q&A
  3. 3. Page 3Confidential Design Matter: Doing Better with Less
  4. 4. Introduction Page 4Confidential S.O.L.I.D is an acronym for the first five object-oriented design(OOD) principles by Robert C. Martin, popularly known as Uncle Bob. S – Single Responsibility principle O – Open-closed principle L – Liskov’s substitution principle I – Interface segregation principle D – Dependency Inversion principle
  5. 5. What are the issues that developers always face to in software development lifecycle? Question
  6. 6. Requirements change Page 6Confidential Your requirements will always change (and grow) over time Your system need to evolve to handle the changes. We should build a software which is smartly designed enough to change. .
  7. 7. What is “Smartly-designed Software” ? Page 7Confidential Handle the changes with minimal re-factor and effort. Extendable Reusable Flexible
  8. 8. Customer and Developer satisfaction Page 8Confidential Customers are satisfied because the software: + Work well + Keeps working - always. + Can be changed, upgraded easily + Reuse to build other software. + Extendable, Flexible. Help the developers: + Handle the changes easily. + Code better in any programming languages.
  9. 9. Page 9Confidential PURPOSE OF USE When combined together, these principles will help your software:  Become well and smartly-designed  Easily handle the changes  Make both customer and developer satisfied with their work. ⇒Save money and time.
  10. 10. Single Responsibility principle (SRP) Page 10Confidential
  11. 11. SRP - Definition Page 11Confidential “An object should have one and only one reason to change”
  12. 12. SRP - Explanation Page 12Confidential Responsibility is a family of functions that serves one particular purpose. If you have a class having more than one reason to change => you should split the class into multiple classes base on their responsibilities.
  13. 13. SRP - Example Page 13Confidential
  14. 14. SRP – Why splitting is important ? Page 14Confidential - If classes have more than one responsibility ? - Each responsibility is an axis of change. + Codes become complicated + One change effects another - Big classes: + Difficult to change + Harder to read + Bugs
  15. 15. SRP – Benefit Page 15Confidential Increase the reusability of source code Make your classes smaller, lesser complicated. Restrict effects to other modules when we change source codes. Easier to read and write => less to write bugs. Higher cohesion, lower coupling. Smaller classes and smaller methods will give you more flexibility More classes != more complicated
  16. 16. Open – Close Principle (OCP) Page 16Confidential
  17. 17. OCP - Definition Page 17Confidential “An object should be opened for extension and closed for modification”
  18. 18. OCP - Explanation Page 18Confidential - You should extend a class without modifying it. - if you read and understand all source code to find what they are supposed to do and update. ⇒ so hard ⇒ cost time, effort ⇒ bugs - But it’s easy to extend the source code to meet the new requirements.
  19. 19. OCP - Example Page 19Confidential
  20. 20. OCP – Benefit Page 20Confidential - Restrict effects to others because when you change code. - Not need to read all old source codes that already worked well. - Extend the existing libraries.
  21. 21. - Template Method Design Pattern - Strategy Design Pattern. Reference
  22. 22. Liskov's Substitution (LSP) - Definition Page 22Confidential “Objects should be replaceable with their base classes without altering the correctness of the program”
  23. 23. LSP - Explanation Page 23Confidential + Should always use a base class or interface instead of the subclasses. + This works correctly with any subclasses of X. ⇒ Extends without replacing any base class's functions
  24. 24. LSP - Example Page 24Confidential
  25. 25. LSP – Benefit Page 25Confidential - This is an extension of OCP ⇒Wrong LSP => wrong OCP ⇒ Inherit all OCP's benefits. - Preventing bugs caused by subclasses.
  26. 26. Interface segregation Principle (ISP) Page 26Confidential
  27. 27. ISP - Definition Page 27Confidential “A client should not implement an interface, if it doesn't use that”
  28. 28. ISP - Explanation Page 28Confidential Clients should not be forced to implement interfaces they don't use => Split a fat interface which has many methods into many small interfaces.
  29. 29. ISP - Example Page 29Confidential
  30. 30. ISP – Benefit Page 30Confidential - Smaller interface => more reusable - Extendable - Flexible - Allows people to use only the parts of objects that they need. - High cohesion, low coupling - Comply SRP.
  31. 31. Dependence Inversion Principle (DIP) Page 31Confidential
  32. 32. DIP - Definition Page 32Confidential “High level model should not depend on low level module, both should depend on abstractions Abstractions should not depend on details. Details should depend on abstractions”
  33. 33. DIP - Explanation Page 33Confidential - Low level module: implement basic and primary operations - High level module: encapsulate complex logic - The high level classes should not directly use and heavily depend on low level classes. => we should create abstraction layer between high level classes and low level classes
  34. 34. DIP - Example Page 34Confidential
  35. 35. Demo - Explanation Page 35Confidential
  36. 36. DIP - Explanation Page 36Confidential - Abstractions should not depend upon details - Details should depend on abstractions
  37. 37. Page 37Confidential - Spring frameworks' component - Using Dependency Injection pattern - Automatic class instantiation (from external files or annotation) - Entirely remove the low-level component dependencies and achieve true DIP. IoC Container & Dependency Injection
  38. 38. DIP – Benefit Page 38Confidential - Reusable - Flexible - More readable. - Higher cohesion - lower coupling - Remove dependencies between low and high level modules. - Violate DIP => Violate OCP or LSP. - More classes != More complicated
  39. 39. Should we always apply DIP anywhere? Question
  40. 40. Conclusion Page 40Confidential With S.O.L.I.D principles, our software:  Easily handle the changes  Become well and smartly-designed  Make both customer and developer satisfied with their work. ⇒Save money and time.
  41. 41. OOP vs OOD Page 41Confidential Object oriented design (OOD) = OOP + Design principles. ⇒The source code applied OOD will be: + Object oriented + Re-usable + Flexible: can be changed with minimal efforts. + Extendable: can be extended without changing existing codes
  42. 42. Q&A Page 42Confidential
  43. 43. References Page 43Confidential architecture-principles-using-simple-Csharp object-oriented-design Object oriented analysis and design book by Head First Design pattern Dependency Injection and IoC container in Spring Framework