Object re-orientation

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.

D5a2aef3c745cca287ddef1948157fd3?s=128

carnage

June 08, 2018
Tweet

Transcript

  1. Object reorientation Christopher Riley Dutch PHP Conference 2018 1

  2. Introduction

  3. Why? 1

  4. Solid

  5. Solid • Single responsibility principle 2

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

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

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

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

    substitution principle • Interface segregation principle • Dependency inversion principle 2
  10. Dry

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

    yourself • Don’t repeat yourself 3
  12. What is the hardest part of software development? 3

  13. Reducing bugs

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

    3
  15. Reduce invalid states 4

  16. Reduce invalid states 5

  17. Reduce invalid states 6

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

  19. Objects should always be valid 7

  20. Objects should always be valid 8

  21. Encapsulate internal state 8

  22. Encapsulate internal state 9

  23. Encapsulate internal state 10

  24. Use type hints 10

  25. Use type hints 11

  26. Use type hints 12

  27. Change state or return something never both 12

  28. Change or return 13

  29. Change or return 14

  30. Change or return 14

  31. Change or return 15

  32. Be careful with mutable values 15

  33. Mutable values 16

  34. Mutable values 17

  35. Mutable values 18

  36. Knowledge as Code

  37. A case study 19

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

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

    12345678 19
  40. Basic validation 20

  41. Mod 11 validation 21

  42. What was the problem? 21

  43. What now? 21

  44. Rule classes 22

  45. The validator 23

  46. A value object 24

  47. A value object 25

  48. The factory 26

  49. Conclusion

  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
  51. Thanks • @giveupalready • https://github.com/carnage • https://carnage.github.io • https://joind.in/talk/09ee3 27