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

520 views

Published on

Slides used in:
https://www.meetup.com/dotnetters/events/244837187/?eventId=244837187

Published in: Engineering
  • Be the first to comment

Solid

  1. 1. SOLID @alfredodev afernandez@plainconcepts.com
  2. 2. SOLID • Acronim of five principles • Principles, not laws • A bit vague or abstract • They are all interelated • A bit marketing oriented (ejem Uncle Bob ;) ) • A bit criticized • By Michael Feathers or Robert Martin
  3. 3. Critics • Simple code • Testeable code • Low cohesion high coupling
  4. 4. Critics • Simple code • Testeable code • Low cohesion high coupling • Low coupling high cohesion
  5. 5. @gerard_lopz @quiqu3 @alfredodev
  6. 6. @gerard_lopz @quiqu3 @alfredodev SOLID!
  7. 7. https://github.com/joebew42/study-path
  8. 8. SOLID
  9. 9. Single Responsibility Principle
  10. 10. Single Responsibility Principle A class should have only one responsibility. Each software module should have one and only one reason to change.
  11. 11. Single Responsibility Principle What is a responsibility?
  12. 12. Single Responsibility Principle What is a reason to change?
  13. 13. Example 1
  14. 14. Cohesion • Cohesion refers to the degree to which the elements inside a module belong together
  15. 15. Cohesion • Cohesion refers to the degree to which the elements inside a module belong together
  16. 16. Responsibilities to whom? • Classes have responsibilities to their users, those users can be classified into actors based on the roles that they play on the application. • A responsibility is a family of functions that serves a particular actor.
  17. 17. Example 1 Support Banking Tinder? IT / operations
  18. 18. Single Responsibility Principle What about methods?
  19. 19. Example 2
  20. 20. Tips • Describe what the class does in one sentece (did you use the word and or or?) • Please Mr Object what is your Property
  21. 21. What are your thoughts?
  22. 22. SOLID
  23. 23. Open Close Principle
  24. 24. Open Close Principle A software module should be open for extension and close for modification Change a module behaviour without changing its source code
  25. 25. Examples
  26. 26. Related • Encapsulation • Abstraction • Dependency Inversion
  27. 27. What are your thoughts?
  28. 28. SOLID
  29. 29. Liskov Substitution Principle
  30. 30. Liskov substitution Principle If S is a subtype of T, then objects of type T may be replaced with objects of type S If the base class does something, the inherited class must do it too and in a way that doesn't violate the expectations of the users of the base class
  31. 31. Examples
  32. 32. Simptoms • Inherited class with empty methods that are implemented in the base class • Inherited class with that throw exceptinos • Check If typeof (x) on the base class
  33. 33. I’ve fucked up Screen SearchScreen ComplexSearch SimpleSearch MaintenanceScreen SimpleMaintenance TabbedMaintenance
  34. 34. I’ve fucked up Screen SearchScreen ComplexSearch SimpleSearch MaintenanceScreen SimpleMaintenance TabbedMaintenance SpecialMaintenanceWithSearch
  35. 35. What about dynamic languages • Dynamic languages are different • Duck typing • It’s harder but the same principles should apply
  36. 36. Tips • Don’t have high hirerarchies of objects • Favor composition over inheritance
  37. 37. What are your thoughts?
  38. 38. SOLID
  39. 39. Interface Segregation Principle
  40. 40. Interface Segregation Principle No client should be forced to depend on methods it does not use Interfaces have more to do with the classes that use them than with the classes that implement them
  41. 41. Examples
  42. 42. Depending on not used methods • Forces you to recompile when those methods change • Forces you to redeploy
  43. 43. Depending on not used methods • Makes it harder to understand
  44. 44. Depending on not used methods • Makes it harder to reuse • Forces you to have empty mehods
  45. 45. What are your thoughts?
  46. 46. SOLID
  47. 47. Dependency Inversion Principle
  48. 48. Dependency Inversion Principle High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.
  49. 49. Dependency Injection
  50. 50. Inversion of control
  51. 51. Dependency Inversion Principle High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.
  52. 52. Dependency Inversion
  53. 53. Dependency Inversion Principle Should we abstract everything?
  54. 54. SOLID Should we make a milion tiny classes?
  55. 55. https://www.youtube.com/watch?v=llGgO74uXMI Core Design Principles for Software Developers by Venkat Subramaniam
  56. 56. 4 rules of simple design • Passes the tests • Reveals intention • No duplication • Fewest elements
  57. 57. TRUE • Transparent: The consequence of change should be obvious in the code that is changing and in distant code that relies upon it • Reasonable: The cost of any change should be proportional to the benefits the change achieves • Usable: The code should be usable in new and unexpected contexs • Exemplary: The code itself should encourage those that use it to perpetuate those qualities
  58. 58. Thank you! Now questions! and more thoughts? @alfredodev afernandez@plainconcepts.com

×