Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Igor Kochetov "What is wrong with Dependency Injection? Myths and Truths"

122 vues

Publié le

It's 2019 and DI is a well-known and established technique on all major platforms and languages. So why can't we still have a clear answer to the questions like 'is DI/IoC container a mandatory thing to apply DI?' or 'what is a true way to implement DI in language/platform X?' or ‘is it even a good/useful thing?’.

Let's find those answers together and refresh our memory on the initial goals and targets of DI and its surrounding design patterns.

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Igor Kochetov "What is wrong with Dependency Injection? Myths and Truths"

  1. 1. What is wrong with Dependency Injection? Igor Kochetov (@ k04a) Unity Technologies
  2. 2. @k04a The DI book 2 Authored by: Mark “ploeh” Seemann Steven “.NET Junkie” van Deursen
  3. 3. Who am I? Dev (C#, Python) in Opsy (Docker, k8s, GCP) world Attendee: NDC (Oslo), New Crafts (Paris) Speaker: BuildStuff (Vilnius), XP Days & .Net Fest (Kyiv) Religious about engineering practices and team culture, software design and good code Toolsmith at Unity Technologies, based in Odessa Twitter: @k04a Linkedin: Igor Kochetov
  4. 4. @k04a Why we even talk about DI in 2019? There are conflicting opinions on the subject of DI Is it even still relevant? 4
  5. 5. @k04a What is DI? 5
  6. 6. @k04a Nice one, but there are still questions... Who’s “we” who make sure you have what you need? How do we state “the need” in the code? Why one would use it? What are the benefits, actually? 6
  7. 7. Known benefits Dependency Injection ❏ Reducing dependencies of components (and implementation details of those dependencies) ❏ Reusable code / swapping of components ❏ More testable code ❏ More readable code (by defining dependencies clearly) Loose coupling Isolated components are easier to: ❏ Modify, reuse or compose differently ❏ Test ❏ Reason about 7
  8. 8. @k04a It is about Dependencies... Identifying dependencies in our code (and types of dependencies) Managing dependencies 8
  9. 9. @k04a Programming to interfaces and D in SOLID High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. 9
  10. 10. @k04a Also related: who owns the abstractions? Model abstractions around domain-specific scenarios instead of low-level implementation details “Adapt” external dependencies to match your domain concepts Hexagonal architecture or “Ports & Adapters”: 10
  11. 11. @k04a Programming to interfaces and D in SOLID ServiceX is still tightly coupled to ServiceY! 11
  12. 12. How do we state “the need” in the code? 12
  13. 13. @k04a Resolve dependencies using Service Locator At first, looks like very good idea, which makes it even more dangerous. But now we introduce new dependency (on the container) We also hide actual dependencies How would you write tests for it? 13
  14. 14. @k04a Constructor Injection is the way to go ❏ Explicitly lists dependencies ❏ Gives clues about what class might do ❏ Also an indicator of possible SRP violations 14
  15. 15. @k04a Wiring decoupled codebases 15
  16. 16. Who’s “we” who make sure you have what you need? Or “Mommy and Daddy providing a drink” 16
  17. 17. @k04a Many platforms provide out-of-the box DI capabilities .NET MVC / .NET Core MVC Spring in Java Angular JS Kind of making it a de-facto standard 17
  18. 18. Myth: DI is a software library or a framework Or at least requires one to be done properly @k04a 18
  19. 19. @k04a IoC Container or DI Container Container - software library that ‘resolves dependencies’ and manages their ‘lifetime’ ❏ Simplifies wiring and reduces maintenance ❏ Simplifies testing ❏ Allows for dynamic configuration ❏ Supports AOP But… Is it? 19
  20. 20. @k04a Manually registering components in the container 20
  21. 21. @k04a Composition Root and Pure DI Creating all the stuff ‘normally’ in Composition Root (console app example) 21
  22. 22. @k04a Is it OK to have all the components in the app root? It is good idea to keep individual components separated Until we have to actually assemble working application 22
  23. 23. @k04a Explicit is better than implicit (Zen of Python) Cost of writing vs cost of reading (or imagine bringing a new member of the team into the codebase) Let IDE and code analysis tools be your friends It is actually IMPORTANT to know, what your app does (well-structured Composition Root serves as documentation providing bird-eye view on high-level features and use- cases) 23
  24. 24. @k04a Composing within framework (.Net Core MVC) As easy as registering a custom IControllerActivator 24
  25. 25. @k04a Composing within framework (.Net Core MVC) … and implementing it 25
  26. 26. @k04a Use-case for Aspect-Oriented-Programming Applying cross-cutting concerns (also known as non-functional requirements) like: ❏ Logging ❏ Caching ❏ Security 26
  27. 27. @k04a The power of Decorators (or AOP done right) Wrap logging around any actual implementation using Decorator design pattern 27
  28. 28. @k04a Injecting decorated dependency Wrap any number of cross-cutting concerns around actual implementation 28
  29. 29. @k04a Applying SOLID to extreme pushes you toward FP A lot of single-method interfaces and small focused classes (implementations) Which is good, until you have to write Decorators for every of them 29
  30. 30. @k04a CQS and Parameter Object Single generic abstraction Implementation consists of two types: ❏ Command ❏ CommandHandler 30
  31. 31. @k04a Decorator over generic ICommandHandler Now every ‘aspect’ becomes single Decorator over generic ICommandHandler <TCommand> interface 31
  32. 32. @k04a Decorator over generic ICommandHandler Write once, use for all kinds of Commands 32
  33. 33. @k04a Conclusions & takeaways Container is a dependency itself It also might be a sign your codebase grew too big (read “monolith”) DI ≠ Container DI is useful as a design pattern and allows greater flexibility and more manageable codebase (easier to test, modify and reason about) 33
  34. 34. @k04a The big idea (or what those have in common?) ❏ Dependency Injection (DI) ❏ Continuous Integration (CI) / Continuous Deployment (CD) ❏ Scrum, Lean or any Agile methodology / framework of your choice ❏ DevOps Answer: Those were meant to be PRACTICES (not Tools) 34
  35. 35. Q & A 35