Of course, you should read all you can about SOLID, Design patterns, Patterns of Enterprise Application Architecture, etc. Once you have a basic understanding of these topics you still have to write that code though, and write it well too! What is good code? Are there some guidelines, or rules of thumb, which you can follow while making your everyday coding decisions? In this talk I’ll cover many of these coding guidelines, which aren’t usually covered by patterns or principles books. They should help you write better code and give you a richer vocabulary for reviewing other people’s code. Some of the subjects that we’ll discuss are: state, mutability, CQS, one-method objects, domain-first, API-driven, functional programming influences, object boundaries, (de)serialization, and many more!

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

6. Strings
Integers Booleans
Floats

9. Domain concepts
Use cases
Infra-stuff

10. Objects introduce meaning

11. Strings
Email
addresses

12. OBJECTS ENCAPSULATE
STATE AND BEHAVIOR
enclose

13. a = …
b = …

14. behaviorA()
behaviorB()

15. Behavior
State
Primitive
values
Services
Entities
Value
objects
Anemic
domain
objects

16. Find a balance

17. SERVICES SHOULD BE
MODELLED AS FUNCTIONS

18. behaviorA()
behaviorB()
somewhatUnrelated()
!!!

19. somewhatUnrelated()
behaviorA()
behaviorB()Because: SRP

20. behaviorA()
behaviorB()

21. behaviorB()
Because: ISP
behaviorA()

22. Single-method classes
~=
Functions

23. http://blog.ploeh.dk/...

24. Functions
Naturally stateless

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”);
}

30. logger
log()
repository
add()

31. add()
log()
RegisterUser

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

39. construct()
Something is
not right!!!?

40. behaviorB()
First call
behaviorA()!!!?

41. canCallBehaviorB()
behaviorB()
Yes
Tell, don’t ask
Anemic domain
model
?

42. YesValidatorisValid( )

43. How to prevent this?
?

44. What about…
changeState( , , )
?

45. ONLY VALID VALUES SHOULD
CROSS OBJECT BOUNDARIES

46. Crossing boundaries
Arguments
Return values,
Exceptions

47. changeState(...) {
check pre-conditions
...
check post-conditions
}

48. changeState()
doSomething()
getSomething()
construct()

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

61. Command
Query Document

62. Command
Query Document

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

72. Apply CQS
Command
Query

73. Prefer immutability
Query
Document

74. This design emerges

75. Your application has side-
effects
Filesystem
Keyboard
Screen
Network

76. Apply hexagonal
architecture

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

83. Also…
Try Event Sourcing

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