From STUPID to SOLID code!

STUPID and SOLID are two acronyms that explain what you should and should NOT do while writing OOP code. These slides introduce a few basic principles of OOP and Design.

Online slides: http://williamdurand.fr/from-stupid-to-solid-code-slides/
Source: https://github.com/willdurand/from-stupid-to-solid-code-slides

Transcript

1. FROM
   FROM STUPID
   STUPID TO
   TO SOLID
   SOLID CODE!
   CODE!
   A few basic principles of Object-Oriented Programming and Design.
   

   View Slide

2. DISCLAIMER
   DISCLAIMER
   THESE ARE PRINCIPLES, NOT LAWS!
   THESE ARE PRINCIPLES, NOT LAWS!
   

   View Slide

3. STUPID
   STUPID CODE, SERIOUSLY?
   CODE, SERIOUSLY?
   

   View Slide

4. WHAT MAKES CODE
   WHAT MAKES CODE STUPID
   STUPID?
   ?
   Singleton
   Tight Coupling
   Untestability
   Premature Optimization
   Indescriptive Naming
   Duplication
   

   View Slide

5. S
   SINGLETON
   INGLETON
   Programs using global state are very difficult to test.
   Programs that rely on global state hide their dependencies.
   Why Singletons Are Controversial
   Why is Singleton considered an anti pattern?
   So Singletons are bad, then what?
   

   View Slide

6. T
   TIGHT COUPLING
   IGHT COUPLING
   Generalization of the Singleton issue.
   Also known as strong coupling.
   Reducing Coupling (Martin Fowler)
   

   View Slide

7. U
   UNTESTABILITY
   NTESTABILITY
   Testing should not be hard!
   Whenever you don't write unit tests because you don't have
   time, the real issue is that your code is bad.
   

   View Slide

8. P
   PREMATURE OPTIMIZATION
   REMATURE OPTIMIZATION
   Premature optimization is the root of all evil. — Donald Knuth
   There is only cost and no benefit.
   PrematureOptimization Anti-Pattern
   

   View Slide

9. IINDESCRIPTIVE NAMING
   NDESCRIPTIVE NAMING
   Name your classes, methods, attributes, and variables properly.
   Don't abbreviate, never!
   

   View Slide

10. D
    DUPLICATION
    UPLICATION
    Don't Repeat Yourself!
    Keep It Simple, Stupid!
    

    View Slide

11. View Slide

12. SOLID
    SOLID TO THE RESCUE!
    TO THE RESCUE!
    

    View Slide

13. SOLID
    SOLID
    A term describing a collection
    of design principles for good
    code that was coined by
    Robert C. Martin also known
    as Uncle Bob.
    

    View Slide

14. S
    SOLID
    OLID
    

    View Slide

15. S
    SINGLE RESPONSIBILITY PRINCIPLE (SRP)
    INGLE RESPONSIBILITY PRINCIPLE (SRP)
    There should never be more than one reason
    for a class to change.
    The Single Responsibility Principle
    

    View Slide

16. Just because you can, doesn't mean you should!
    

    View Slide

17. #PROTIPS
    #PROTIPS
    Split big classes
    Use layers
    Avoid god classes
    Write straightforward comments
    

    View Slide

18. S
    SO
    OLID
    LID
    

    View Slide

19. O
    OPEN/CLOSED PRINCIPLE (OCP)
    PEN/CLOSED PRINCIPLE (OCP)
    Software entities should be open for extension,
    but closed for modification.
    The Open-Closed Principle
    

    View Slide

20. View Slide

21. #PROTIPS
    #PROTIPS
    Make all member variables private
    No global variables, ever
    Avoid setters (as much as possible)
    

    View Slide

22. SO
    SOL
    LID
    ID
    

    View Slide

23. L
    LISKOV SUBSTITUTION PRINCIPLE (LSP)
    ISKOV SUBSTITUTION PRINCIPLE (LSP)
    Objects in a program should be replaceable with instances of
    their subtypes without altering the correctness of the program.
    Liskov Substitution Principle
    The Liskov Substitution Principle
    

    View Slide

24. View Slide

25. SOL
    SOLIID
    D
    

    View Slide

26. IINTERFACE SEGREGATION PRINCIPLE (ISP)
    NTERFACE SEGREGATION PRINCIPLE (ISP)
    Many client-specific interfaces are better than one
    general-purpose interface.
    The Interface Segregation Principle
    

    View Slide

27. View Slide

28. SOLI
    SOLID
    D
    

    View Slide

29. D
    DEPENDENCY INVERSION PRINCIPLE (DIP)
    EPENDENCY INVERSION PRINCIPLE (DIP)
    High level modules should not depend upon low level modules.
    Both should depend upon abstractions.
    Abstractions should not depend upon details. Details should
    depend upon abstractions.
    DIP in the Wild
    Dependency Inversion Principle
    The Dependency Inversion Principle
    Dependency Injection Is NOT The Same As The Dependency Inversion Principle
    

    View Slide

30. View Slide

31. CONCLUSION
    CONCLUSION
    Avoiding tight coupling is the key!
    Use your brain.
    Writing SOLID code is not that hard.
    

    View Slide

32. THANK YOU, QUESTIONS?
    THANK YOU, QUESTIONS?
    williamdurand.fr
    github.com/willdurand
    twitter.com/couac
    

    View Slide

33. CREDITS
    CREDITS
    http://lostechies.com/derickbailey/2009/02/11/solid-
    development-principles-in-motivational-pictures/
    

    View Slide