SOLID/STUPID

Base de cours autour des principes SOLID et STUPID

Transcript

1. STUPID Code !
   Make it SOLID
   

   View Slide

2. STUPID Code !
   Make it SOLID
   

   View Slide

3. Principles, not laws
   

   View Slide

4. You’re code is STUPID !
   

   View Slide

5. S
   T
   U
   P
   I
   D
   

   View Slide

6. S
   T
   U
   P
   I
   D
   ingleton
   

   View Slide

7. Global State
   

   View Slide

8. Hidden dependencies
   

   View Slide

9. But not impossible
   Difficult to test
   

   View Slide

10. S
    T
    U
    P
    I
    D
    ight coupling
    

    View Slide

11. Interaction level between
    components
    

    View Slide

12. Difficult to change
    

    View Slide

13. Difficult to reuse
    

    View Slide

14. Difficult to test
    

    View Slide

15. Avoiding “new”
    

    View Slide

16. S
    T
    U
    P
    I
    D
    ntestability
    

    View Slide

17. Everything must be easy
    to test
    

    View Slide

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

    View Slide

19. S
    T
    U
    P
    I
    D
    remature Optimization
    

    View Slide

20. Premature optimization is
    the root of all evil
    

    View Slide

21. Optimize only if it’s
    necessary
    

    View Slide

22. Optimize timely
    

    View Slide

23. Don’t do it (yet) !
    

    View Slide

24. Readability > Optimization
    

    View Slide

25. S
    T
    U
    P
    I
    D
    ndescriptive naming
    

    View Slide

26. Name properly
    

    View Slide

27. Names came from your
    domain
    

    View Slide

28. Don’t abbreviate
    

    View Slide

29. Don’t prefix/suffix
    

    View Slide

30. The length of a variable
    name should be
    proportional to its scope.
    The length of a function or
    class name is the inverse.
    

    View Slide

31. “You should name a
    variable using the same care
    with which you name a
    first-born child.”
    

    View Slide

32. Programming languages are
    for humans, not for
    computers
    

    View Slide

33. Code > Comments
    

    View Slide

34. Code = How
    

    View Slide

35. Tests = What
    

    View Slide

36. Comments = Why
    

    View Slide

37. S
    T
    U
    P
    I
    Duplication
    

    View Slide

38. Be lazy
    Don’t Repeat Yourself
    

    View Slide

39. Be lazy
    Don’t Repeat Yourself
    

    View Slide

40. Most of time
    Copy/Paste is bad
    

    View Slide

41. Use a Copy/Paste
    Detector
    

    View Slide

42. Make it SOLID plz !
    

    View Slide

43. S
    O
    L
    I
    D
    

    View Slide

44. S
    O
    L
    I
    D
    ingle responsability
    

    View Slide

45. Every class should have a
    single responsibility
    

    View Slide

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

    View Slide

47. God classes
    

    View Slide

48. Don’t make your
    controller be God Objects
    

    View Slide

49. Avoid Mutators
    

    View Slide

50. Ask yourself what is class
    responsablity
    

    View Slide

51. Keep it as small as
    possible
    

    View Slide

52. S
    O
    L
    I
    D
    pen/Close
    

    View Slide

53. Open for extension, but
    closed for modification
    

    View Slide

54. extend > modify
    

    View Slide

55. setup > modify
    

    View Slide

56. S
    O
    L
    I
    D
    iskov substitution
    

    View Slide

57. Objects should be
    replaceable with
    instances of their
    subtypes without altering
    the correctness of the
    program.
    

    View Slide

58. A square is NOT a
    rectangle
    

    View Slide

59. The mouse case
    

    View Slide

60. S
    O
    L
    I
    D
    nterface segregation
    

    View Slide

61. Many clients > One
    Generic Client
    

    View Slide

62. Don’t over-interface
    

    View Slide

63. S
    O
    L
    I
    Dependency injection
    

    View Slide

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

    View Slide

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

    View Slide

66. Be pragmatic
    

    View Slide

67. Exercice
    

    View Slide

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

    View Slide