Object re-orientation

We are all SOLID developers who like to keep DRY, these are rules we stick to to try keep our code clean. Despite this, we often end up writing procedural code wrapped up inside objects. This code can be hard for our colleagues and collaborators to get to grips with and understand.

Join me for this object reorientation as we take a look at how we can leverage the power of object oriented design to write code which is not just SOLID, but easy to reason about and easy for others to understand.

Transcript

1. Object reorientation
   Christopher Riley
   Dutch PHP Conference 2018
   1
   

   View Slide

2. Introduction
   

   View Slide

3. Why?
   1
   

   View Slide

4. Solid
   

   View Slide

5. Solid
   • Single responsibility principle
   2
   

   View Slide

6. Solid
   • Single responsibility principle
   • Open/closed principle
   2
   

   View Slide

7. Solid
   • Single responsibility principle
   • Open/closed principle
   • Liskov substitution principle
   2
   

   View Slide

8. Solid
   • Single responsibility principle
   • Open/closed principle
   • Liskov substitution principle
   • Interface segregation principle
   2
   

   View Slide

9. Solid
   • Single responsibility principle
   • Open/closed principle
   • Liskov substitution principle
   • Interface segregation principle
   • Dependency inversion principle
   2
   

   View Slide

10. Dry
    

    View Slide

11. Don’t repeat yourself
    • Don’t repeat yourself
    • Don’t repeat yourself
    • Don’t repeat yourself
    3
    

    View Slide

12. What is the hardest part of software
    development?
    3
    

    View Slide

13. Reducing bugs
    

    View Slide

14. Write code which reduces the possible number
    of invalid states
    3
    

    View Slide

15. Reduce invalid states
    4
    

    View Slide

16. Reduce invalid states
    5
    

    View Slide

17. Reduce invalid states
    6
    

    View Slide

18. An object should always be in a valid state
    6
    

    View Slide

19. Objects should always be valid
    7
    

    View Slide

20. Objects should always be valid
    8
    

    View Slide

21. Encapsulate internal state
    8
    

    View Slide

22. Encapsulate internal state
    9
    

    View Slide

23. Encapsulate internal state
    10
    

    View Slide

24. Use type hints
    10
    

    View Slide

25. Use type hints
    11
    

    View Slide

26. Use type hints
    12
    

    View Slide

27. Change state or return something never both
    12
    

    View Slide

28. Change or return
    13
    

    View Slide

29. Change or return
    14
    

    View Slide

30. Change or return
    14
    

    View Slide

31. Change or return
    15
    

    View Slide

32. Be careful with mutable values
    15
    

    View Slide

33. Mutable values
    16
    

    View Slide

34. Mutable values
    17
    

    View Slide

35. Mutable values
    18
    

    View Slide

36. Knowledge as Code
    

    View Slide

37. A case study
    19
    

    View Slide

38. A case study
    • Sort code: 12-34-56
    19
    

    View Slide

39. A case study
    • Sort code: 12-34-56
    • Account number: 12345678
    19
    

    View Slide

40. Basic validation
    20
    

    View Slide

41. Mod 11 validation
    21
    

    View Slide

42. What was the problem?
    21
    

    View Slide

43. What now?
    21
    

    View Slide

44. Rule classes
    22
    

    View Slide

45. The validator
    23
    

    View Slide

46. A value object
    24
    

    View Slide

47. A value object
    25
    

    View Slide

48. The factory
    26
    

    View Slide

49. Conclusion
    

    View Slide

50. The purpose of abstraction is not to be vague,
    but to create a new semantic level in which
    one can be absolutely precise. - Dijkstra
    26
    

    View Slide

51. Thanks
    • @giveupalready
    • https://github.com/carnage
    • https://carnage.github.io
    • https://joind.in/talk/09ee3
    27
    

    View Slide