Building SOLID Software with Dependency Injection

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. What does this method do? • 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. What does this class do? • 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?