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

SOLID/STUPID

GBProd
February 20, 2017

 SOLID/STUPID

Base de cours autour des principes SOLID et STUPID

GBProd

February 20, 2017
Tweet

More Decks by GBProd

Other Decks in Programming

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