Downloaded 51 times
![public void doSomething(...) {
...
}
public [return-type] getSomething(...) {
return ...
}](https://image.slidesharecdn.com/beyonddesignpatternsandprinciples-160513124458/75/Beyond-design-patterns-and-principles-writing-good-OO-code-63-2048.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/beyonddesignpatternsandprinciples-160513124458/75/Beyond-design-patterns-and-principles-writing-good-OO-code-67-2048.jpg)
Uploaded byMatthias Noback
Beyond design patterns and principles - writing good OO code
The document discusses principles and practices for writing good object-oriented (OO) code, emphasizing the importance of design patterns, immutability, and encapsulation. It advocates for modeling services as functions, ensuring that objects maintain valid states, and using well-defined message communication. The conclusion reiterates that everything is an object, highlighting the need for explicit side-effects and clear boundaries in OO design.
More Related Content
Similar to Beyond design patterns and principles - writing good OO code
![[DevDay2018] Let’s all get along. Clean Code please! - By: Christophe K. Ngo,...](https://cdn.slidesharecdn.com/ss_thumbnails/christophek-180419103038-thumbnail.jpg?width=640&height=640&fit=bounds)
Beyond design patterns and principles - writing good OO code
- 1. BEYOND DESIGN PATTERNS &PRINCIPLES WRITING GOOD OO CODE Before? Matthias Noback @matthiasnoback
- 2. My goals To giveyou 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 Chainof responsibility Command Mediator Strategy Observer
- 4. Single responsibility principle Open/closedprinciple Liskov substitution principle Interface segregation principle Dependency inversion principle
- 5. EVERYTHING IS ANOBJECT Alan Kay
- 6.
- 9.
- 10.
- 11.
- 12. OBJECTS ENCAPSULATE STATE ANDBEHAVIOR enclose
- 13. a = … b= …
- 14.
- 15.
- 16.
- 17. SERVICES SHOULD BE MODELLEDAS FUNCTIONS
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25. class TheClass { public doSomething(...) { checkpre-conditions happy path handle failure check post-conditions } }
- 26. Simpler design, easierto test The unit is smaller Small number of possible execution paths No unexpected changes in behavior
- 27. OBJECTS SHOULD BEEXPLICIT ABOUT SIDE-EFFECTS
- 28. class RegisterUser { private repository privatelogger 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”); }
- 30.
- 31.
- 32. INJECTED SERVICES SHOULDBE SINGLE-METHOD OBJECTS TOO
- 33. function registerUserFactory(repository, logger) { returnfunction(name) { repository.add(new User(name)); logger.log(“New user added”); } } registerUser = registerUserFactory( repository, logger ); registerUser(“Matthias”);
- 34. No service locators serviceLocator.get(‘serviceid’).method() Inject this object instead!
- 35. No train wrecks someService.getOtherService.doSomething() Injectthis object instead!
- 36. Inject only single-method services Side-effectswill be explicit Responsibilities will be more explicit Dependencies will be easier to mock
- 37. OBJECTS SHOULD ONLY EXISTIN A VALID STATE condition
- 38.
- 39.
- 40.
- 41.
- 42.
- 43. How to preventthis? ?
- 44.
- 45. ONLY VALID VALUESSHOULD CROSS OBJECT BOUNDARIES
- 46.
- 47. changeState(...) { check pre-conditions ... checkpost-conditions }
- 48.
- 49. Advantages of always-valid objects Easyto debug Easy to refactor Easy to reason about
- 50. ALMOST ALL OBJECTS SHOULDBE IMMUTABLE unable to be changed
- 52.
- 53.
- 54.
- 55. Advantages of immutability Cleardistinction between using state and changing state Pass on objects without worrying Use objects without worrying
- 56. Easier to reasonabout
- 57. OBJECTS SHOULD COMMUNICATE USINGWELL-DEFINED MESSAGES “Alan Kay”
- 59.
- 60. Calling methods == Sending messages Receivingreturn values == Receiving messages Catching exceptions == Receiving messages
- 61.
- 62.
- 63. public void doSomething(...){ ... } public [return-type] getSomething(...) { return ... }
- 64. CQS: command-query separation Asking forinformation doesn’t change observable state
- 65. EVERYTHING IS ANOBJECT
- 66.
- 67. “I thought ofobjects 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 alwaysbe valid Command Command Command
- 72.
- 73.
- 74.
- 75. Your application hasside- effects Filesystem Keyboard Screen Network
- 76.
- 77. IN WHICH WAYSIS YOUR APPLICATION NOT AN OBJECT?
- 81.
- 82. Some suggestions Write theserialization code yourself The object’s design always comes first Don’t let tools mess with object encapsulation
- 83.
- 84.
- 85. EVERYTHING IS ANOBJECT 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