1. Building SOLID Software with Dependency Injection Jeremy Rosenberg

2. Me

8. Who cares about software design?

9. What are our goals? Deliver yesterday Communicate telepathically No bugs

10. What are our goals? Deliver yesterday Communicate telepathically No bugs

11. What are our goals? Deliver quickly Communicate quickly Few bugs Fix bugs quickly Deliver yesterday Communicate telepathically No bugs

12. What are our goals? Deliver quickly Communicate quickly Few bugs Fix bugs quickly Deliver yesterday Communicate telepathically No bugs aka Efficiently deal with Change

13. What is a bad design?

14. A bad design causes these Deliver slowly or unpredictably Slow ramp-up for new team members Slow sharing between veteran team members

15. A bad design causes these Frequent bugs Simple bugs need complex changes Lots of regressions Lots of regression testing

16. What is a good design?

17. What is SOLID?

18. What it is Catchy acronym Principles for dealing with change

19. What it is Catchy acronym Principles for dealing with change

20. What it is Catchy acronym Principles for dealing with change SDOLI

21. What it’s not Framework Library Pattern Goal

22. What is Dependency Injection? Pattern Jives well with SOLID

23. What kinds of code? Object-oriented Statically typed* (code examples are in C#)

24. What does this method do?

25. – Coordinates a book checkout process for a member Checkout Storage

26. What does this method do? – Coordinates a book checkout process for a member Checkout Storage Is that all?

27. What does this class do?

28. Configuration DB Access

29. So what does this method really do? Checkout Storage

30. So what does this method really do? Checkout Storage – Configuration – DB access Implicit!

31. Let’s write a test case

32. SDOLI: Single Responsibility Principle “Do one thing and do it well” Applies to a method, class, service, system, …

34. How do we isolate the coordination?

35. SDOLI: Dependency Inversion Principle Depend on contracts, not implementations Goal: Decouple the single responsibility from implementations of its dependencies

36. SDOLI: Dependency Inversion Principle Depend on a contract at design-time – e.g. IBookRepository or BookRepositoryBase Receive an implementation at runtime – e.g. SqlBookRepository

38. Dependency Injection A class declares its dependencies through its own contract Providing dependencies is someone else’s job

39. Dependency Injection Constructor injection Property injection Method injection

40. Constructor injection

41. Our test case No configuration No database Only coordination

42. All this “just” for test cases? What else have we gained? – “Tightly bound, loosely coupled” Focused responsibility => readability Dependent on behavior, not implementation – Dependencies are explicit Limits unexpected side effects Straightforward (re)usage – Composability

43. You’re a hack!

44. Composition Root Constructs the object graph Lives near the entry point

45. Example: Console app

46. What about that repository?

47. Make the dependencies explicit

48. Updated Composition Root

49. With me?

51. SDOLI: Open/Closed Principle Open for extensibility, closed for modification Add behavior without changing existing code

53. Decorator Inject behavior into an application Man-in-the-middle

54. Example: Document storage

55. Composition Root

56. Add Logging

58. Add Authorization

60. Add Caching

62. Noticing a pattern?

63. Open…

64. Closed.

69. Composite Implements a contract Delegates to others with the same contract

70. Example

71. Build it like this

72. Use it like this

73. A more concrete example

74. Move the responsibility

75. Notify billing

76. Notify inventory

77. Notify shipping

78. Dispatch all notifications

79. Open / closed

80. SDOLI: Liskov Substitution Principle Functions that use pointers to base types must be able to use objects of derived types without knowing it. “Leaky abstraction principle” -Me

82. Is a Square a Rectangle?

83. SetWidth / SetHeight ?

84. Example: calculator

85. Usage

86. Guess what’s next

88. Oops

89. Plug the leak – Part 1

90. - Nine fingers left!

91. Plug the leak – Part 2

92. What to do Some ideas – Kill the abstraction – Adapt each calculator to something that supports input validation

93. Another example: more documents…

94. Read-only integration

95. Oops

96. Plug the leak

97. What to do? Some ideas – IReadOnlyDocRepo and IReadWriteDocRepo – IReadDocs and IWriteDocs – SupportsXYZ methods

98. How can DI help apply the LSP?

99. It can’t.

101. SDOLI: Interface Segregation Principle Thin interfaces are better than fat ones Client-focused

103. Example: more books…

104. Who’s using it?

105. Cache books?

106. Don’t need these

107. These are ok

108. What about these?

109. Client-specific interface

110. Adapter This: or this:

111. Slimmer caching

112. Focused dependencies

113. Let’s review

114. SOLID Principles S ingle Responsibility O pen/Closed L iskov Substitution I nterface Segregation D ependency Inversion

116. I don’t know about you…

117. DI Container Auto-wiring of dependencies Lifetime management

118. Ninject

119. Register

120. Ninject Register Resolve

121. Ninject Register Resolve Release

122. Other containers Castle Windsor Autofac StructureMap Unity …

123. What not to do

124. Don’t use Service Locator

125. Hides dependencies Consumers must use the same container Testing becomes un-fun

126. Don’t use Service Locator Composition root should be the only place referencing the DI Container. General rule: if it’s not just initializing the object graph, it’s not the composition root.

127. Don’t just new it

128. Useless interface definition Same tight coupling No way to swap, decorate, or otherwise compose implementations

129. Don’t be double minded

130. Two paths… Dependencies are still not always apparent Auto-wiring can be difficult

131. Building SOLID software

132. SOLID encourages good designs Dependency injection is a tool to bring closer alignment with SOLID

133. Join us

134. Resources The Principles of OOD http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Dependency Injection in.NET by Mark Seemann ploeh blog – DependencyInjection http://blog.ploeh.dk/CategoryView,category,DependencyInjection.aspxhttp://blog.ploeh.dk/CategoryView,category,DependencyInjection.aspx SOLID (object-oriented design) http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)