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 Design principles


Published on

Published in: Technology, Education
  • Be the first to comment

SOLID Design principles

  1. 1. SOLID Desgin Principles
  2. 2. Our aim is to make software more stable unlike ...
  3. 3. We write code that is …
  4. 4. Rigid
  5. 5. Fragile
  6. 6. Immobile
  7. 7. Making everyones life miserable Source:,miserable-life-of-a-small-cat.html
  8. 8. So WHY SOLID?
  9. 9. It helps us to write code that is ...
  10. 10. Loosely coupled
  11. 11. Highly cohesive
  12. 12. Easily composable
  13. 13. Reusable
  14. 14. SOLID Coined by Robert C Martin Not new, exsiting principles brought together
  15. 15. Single Responsibility Principle (SRP)
  16. 16. Single Responsibility Principle (SRP)Open Closed Principle (OCP)
  17. 17. Single Responsibility Principle (SRP)Open Closed Principle (OCP)Liskov Substitution Principle (LSP)
  18. 18. Single Responsibility Principle (SRP)Open Closed Principle (OCP)Liskov Substitution Principle (LSP)Interface Seggregation Principle (ISP)
  19. 19. Single Responsibility Principle (SRP)Open Closed Principle (OCP)Liskov Substitution Principle (LSP)Interface Seggregation Principle (ISP)Dependency Inversion Principle (DIP)
  20. 20. Single Responsibility Principle
  21. 21. Single Responsibility Principle”There should be NEVER be more than ONE reason for a class to change”
  22. 22. Single Responsibility Principle RectangleComputation ----------------------- GUI application Draw() application Area() GUI What is the issue with this design?
  23. 23. Single Responsibility Principle Rectangle does  Computes the area  Draws it on the GUI How can we fix it?
  24. 24. Single Responsibility Principle RectangleComputation ----------------------- application Area() INHERITS GUIRectangle GUI ----------------------- application Draw() GUI
  25. 25. Single Responsibility Principle JDK follows this (java.awt package)  Graphics2D – drawing shapes  Shape – for representing the geometrical shapes Some other examples:  Task to download a file, parse it, and store it in a database  UserSetting- provide customisation feature, check Access
  26. 26. Open Closed Principle
  27. 27. Open Closed Principle”Modules must be OPEN for extension, CLOSED for modification”
  28. 28. Open Closed PrincipleCoined by Bertrand Meyer
  29. 29. Open Closed PrincipleHow can you add new features without editing the existing module?
  30. 30. Open Closed PrincipleExtend the existing modules!
  31. 31. Open Closed PrincipleHow is it even possible?
  32. 32. Open Closed PrincipleDepend on abstractions, new features can be added by extending the abstractions.
  33. 33. Open Closed Principle Examples- - Drawing shapes- Loan approval process
  34. 34. Liskov Substitution Principle
  35. 35. Liskov Subsitution Principle ”Base classes instances must be replaceable bythe sub class instances without any change in the application”
  36. 36. Liskov Subsitution PrincipleLets go back to an earlier example of Drawing shape
  37. 37. Liskov Subsitution Principle Other examples-- Bird, Flight and Non-Flight - Loading of settings -Rectangle and Square
  38. 38. Interface Seggregation Principle
  39. 39. Inteface Seggregation Principle”Clients should not depend upon the interfaces they do not use”
  40. 40. Inteface Seggregation Principle How can we pollute the interfaces? ORHow do we end up creating Fat interfaces?
  41. 41. Inteface Seggregation PrincipleDoor, Time and TimedDoor example. This example also violates LSP
  42. 42. Inteface Seggregation Principle Possible Solutions  Use delegation- Adapter Pattern  Use multiple inheirtance- Interfaces, Mixins
  43. 43. Dependency Inversion Principle
  44. 44. Dependency Inversion Principle”High level modules should not depend on the lowlevel details modules, instead both should depend on abstractions”
  45. 45. Dependency Inversion Principle Copy Read Keyboard Write PrinterWhats GOOD or BAD about this design?
  46. 46. Dependency Inversion Principle Copy program is NOT REUSABLE  Tightly bound to Keyboard and Printer Read Keyboard and Write Printer are REUSABLE
  47. 47. Dependency Inversion Principle Copy program shouldnt be dependent on the Low level Read/Write modules. How can we correct this?
  48. 48. Dependency Inversion Principle Copy Reader Writer Keyboard Reader Print WriterCopy program now depends on Abstractions- Reader and Writer
  49. 49. Resources Wikipedia – SOLID OO Design Robert C Martin articles. Jim Weirich SOLID Ruby talk at Ruby Conference 2009. Rob Martin interview at Hansel Minutes. … and various other small articles, presentations
  50. 50. Ideas for next learning sessions? GoF Design Patterns  One or two patterns each week with code samples JVM Internals NoSQL Java and Concurrency Functional programming in Java