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
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