Upgrade to Pro — share decks privately, control downloads, hide ads and more …


February 20, 2017


Base de cours autour des principes SOLID et STUPID


February 20, 2017

More Decks by GBProd

Other Decks in Programming


  1. STUPID Code ! Make it SOLID

  2. STUPID Code ! Make it SOLID

  3. Principles, not laws

  4. You’re code is STUPID !

  5. S T U P I D

  6. S T U P I D ingleton

  7. Global State

  8. Hidden dependencies

  9. But not impossible Difficult to test

  10. S T U P I D ight coupling

  11. Interaction level between components

  12. Difficult to change

  13. Difficult to reuse

  14. Difficult to test

  15. Avoiding “new”

  16. S T U P I D ntestability

  17. Everything must be easy to test

  18. If you can’t test, the problem is about design

  19. S T U P I D remature Optimization

  20. Premature optimization is the root of all evil

  21. Optimize only if it’s necessary

  22. Optimize timely

  23. Don’t do it (yet) !

  24. Readability > Optimization

  25. S T U P I D ndescriptive naming

  26. Name properly

  27. Names came from your domain

  28. Don’t abbreviate

  29. Don’t prefix/suffix

  30. The length of a variable name should be proportional to

    its scope. The length of a function or class name is the inverse.
  31. “You should name a variable using the same care with

    which you name a first-born child.”
  32. Programming languages are for humans, not for computers

  33. Code > Comments

  34. Code = How

  35. Tests = What

  36. Comments = Why

  37. S T U P I Duplication

  38. Be lazy Don’t Repeat Yourself

  39. Be lazy Don’t Repeat Yourself

  40. Most of time Copy/Paste is bad

  41. Use a Copy/Paste Detector

  42. Make it SOLID plz !

  43. S O L I D

  44. S O L I D ingle responsability

  45. Every class should have a single responsibility

  46. Never be more than one reason for a class to

  47. God classes

  48. Don’t make your controller be God Objects

  49. Avoid Mutators

  50. Ask yourself what is class responsablity

  51. Keep it as small as possible

  52. S O L I D pen/Close

  53. Open for extension, but closed for modification

  54. extend > modify

  55. setup > modify

  56. S O L I D iskov substitution

  57. Objects should be replaceable with instances of their subtypes without

    altering the correctness of the program.
  58. A square is NOT a rectangle

  59. The mouse case

  60. S O L I D nterface segregation

  61. Many clients > One Generic Client

  62. Don’t over-interface

  63. S O L I Dependency injection

  64. High level modules should not depend on low level modules.

    Both should depend on abstractions.
  65. Abstractions should not depend on details. Details should depend on

  66. Be pragmatic

  67. Exercice

  68. git clone https://github.com/gbprod/solid-stupid.git