Beyond Design Patterns and Principles - PHPBenelux 2017
6 likes1,061 views
The document discusses best practices for writing object-oriented code, emphasizing principles such as the single responsibility principle and immutability. It advocates for services to be modeled as functions and for objects to encapsulate state and behavior while ensuring that side effects are explicit. The conclusion highlights the importance of treating applications as collections of objects that communicate through well-defined messages.
![public void doSomething(...) {
...
}
public [return-type] getSomething(...) {
return ...
}](https://image.slidesharecdn.com/beyonddesignpatternsandprinciplesphpbenelux2017-170126141316/85/Beyond-Design-Patterns-and-Principles-PHPBenelux-2017-63-320.jpg)
![“I thought of objects being like biological cells and/
or individual computers on a network, only able to
communicate with messages […]”
Alan Kay](https://image.slidesharecdn.com/beyonddesignpatternsandprinciplesphpbenelux2017-170126141316/85/Beyond-Design-Patterns-and-Principles-PHPBenelux-2017-67-320.jpg)
Beyond Design Patterns and Principles - PHPBenelux 2017
- 1. BEYOND DESIGN PATTERNS & PRINCIPLES WRITING GOOD OO CODE Before? Matthias Noback @matthiasnoback
- 2. My goals To give you some vocabulary for code discussions and reviews To bring back our focus to the basic ideas behind OOP
- 3. Abstract factory Builder Factory method Singleton Adapter Bridge Composite Facade Proxy Chain of responsibility Command Mediator Strategy Observer
- 4. Single responsibility principle Open/closed principle Liskov substitution principle Interface segregation principle Dependency inversion principle
- 5. EVERYTHING IS AN OBJECT Alan Kay
- 12. OBJECTS ENCAPSULATE STATE AND BEHAVIOR enclose
- 13. a = … b = …
- 16. Find a balance
- 17. SERVICES SHOULD BE MODELLED AS FUNCTIONS
- 25. class TheClass { public doSomething(...) { check pre-conditions happy path handle failure check post-conditions } }
- 26. Simpler design, easier to test The unit is smaller Small number of possible execution paths No unexpected changes in behavior
- 27. OBJECTS SHOULD BE EXPLICIT ABOUT SIDE-EFFECTS
- 28. class RegisterUser { private repository private logger public void register(name) { repository.add(new User(name)); logger.log(“New user added”); } } Side effects!
- 29. function registerUser(name, repository, logger) { repository.add(new User(name)); logger.log(“New user added”); }
- 32. INJECTED SERVICES SHOULD BE SINGLE-METHOD OBJECTS TOO
- 33. function registerUserFactory(repository, logger) { return function(name) { repository.add(new User(name)); logger.log(“New user added”); } } registerUser = registerUserFactory( repository, logger ); registerUser(“Matthias”);
- 34. No service locators serviceLocator.get(‘service id’).method() Inject this object instead!
- 35. No train wrecks someService.getOtherService.doSomething() Inject this object instead!
- 36. Inject only single-method services Side-effects will be explicit Responsibilities will be more explicit Dependencies will be easier to mock
- 37. OBJECTS SHOULD ONLY EXIST IN A VALID STATE condition
- 38. ?
- 41. canCallBehaviorB() behaviorB() Yes Tell, don’t ask Anemic domain model ?
- 43. How to prevent this? ?
- 44. What about… changeState( , , ) ?
- 45. ONLY VALID VALUES SHOULD CROSS OBJECT BOUNDARIES
- 47. changeState(...) { check pre-conditions ... check post-conditions }
- 49. Advantages of always-valid objects Easy to debug Easy to refactor Easy to reason about
- 50. ALMOST ALL OBJECTS SHOULD BE IMMUTABLE unable to be changed
- 52. changeState( )
- 53. ?????? !!!!!!!
- 54. changeState( )
- 55. Advantages of immutability Clear distinction between using state and changing state Pass on objects without worrying Use objects without worrying
- 56. Easier to reason about
- 57. OBJECTS SHOULD COMMUNICATE USING WELL-DEFINED MESSAGES “Alan Kay”
- 59. call( )
- 60. Calling methods == Sending messages Receiving return values == Receiving messages Catching exceptions == Receiving messages
- 63. public void doSomething(...) { ... } public [return-type] getSomething(...) { return ... }
- 64. CQS: command-query separation Asking for information doesn’t change observable state
- 65. EVERYTHING IS AN OBJECT
- 66. YOUR APPLICATION TOO! Sort of…
- 67. “I thought of objects being like biological cells and/ or individual computers on a network, only able to communicate with messages […]” Alan Kay
- 68. a = … b = … behaviorA() behaviorB()
- 69. a = … b = … behaviorA() behaviorB()
- 71. State should always be valid Command Command Command
- 75. Your application has side- effects Filesystem Keyboard Screen Network
- 77. IN WHICH WAYS IS YOUR APPLICATION NOT AN OBJECT?
- 81. ???
- 82. Some suggestions Write the serialization code yourself The object’s design always comes first Don’t let tools mess with object encapsulation
- 84. CONCLUSION
- 85. EVERYTHING IS AN OBJECT OBJECTS ENCAPSULATE STATE AND BEHAVIOR SERVICES SHOULD BE MODELLED AS FUNCTIONS OBJECTS SHOULD BE EXPLICIT ABOUT SIDE-EFFECTS ALMOST ALL OBJECTS SHOULD BE IMMUTABLE TREAT YOUR APPLICATION AS AN OBJECT (AND VICE VERSA) ONLY VALID VALUES SHOULD CROSS OBJECT BOUNDARIES OBJECTS SHOULD ONLY EXIST IN A VALID STATE OBJECTS SHOULD COMMUNICATE USING WELL-DEFINED MESSAGES
- 86. CQRS & event sourcing in the wild Michiel Rook Extremely defensive PHP Marco Pivetta The true value of objects Stijn Vannieuwenhuyse Kafka will get the message across, guaranteed David Zuelke