Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Dependency Injection Lightning Talk

100 visualizaciones

Publicado el

A very, very, very quick introduction to dependency injection. Examples use C# and .NET, written using Visual Studio for Mac.

Publicado en: Software
  • Heal Vitiligo In 21 Days? ➜➜➜
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • What it means when he says he loves you but he's not IN love ➣➣➣
    ¿Estás seguro?    No
    Tu mensaje aparecerá aquí
  • Sé el primero en recomendar esto

Dependency Injection Lightning Talk

  1. 1. …and you: So happy together 
  2. 2.  Here’s the absolute worst explanation ever:  ”Instead of newing up objects, you just call ‘container.resolve’”
  3. 3.  With the definition of, “just call container.Resolve instead of newing an object up”, when you go to a job interview and whiteboard some pseudo- code, they might say something like: Pretty sure this guy voted ‘NO’ on hiring me…
  4. 4.  Merriam Webster Dictionary: “something that is dependent on something else”  For example: “A time-traveling DeLorean’s dependency on plutonium was a real problem in 1955.”  Wikipedia’s definition relative to computer science: “[A dependency is a] coupling, a state in which one object uses a function of another object.”  For example: My app needs to make calls to a web service to get and store data, so my business logic has a dependency on the web service.  When you have a “coupling” of two classes, a loose coupling is the way to go in order to make your code more testable and maintainable for the future.
  5. 5.  3 common types of dependency injection:  Setter Injection  Dependencies are injected through specific property setters. I have never seen this in the wild.  Interface Injection  Classes with dependencies implement an interface that exposes a setter method, and dependencies use this to inject themselves into any class passed to it. I have never seen this in the wild.  Constructor Injection  Yaaaaaaay! Winner winner!! Dependencies are injected through the class constructor. This is the only method I’ve seen in the wild.
  6. 6. Interface: A contract or specification Concrete implementation of the interface
  7. 7.  We want ALL of our dependencies to be based on an interface.  Any service code you write should have an interface. Other classes in your app will rely only on the interface… Not the “concrete” implementation of the interface.  You will definitely run into situations where some 3rd party code does not provide an interface (Microsoft’s HttpClient class, as a ubiquitous for-instance).  Never give up… Never surrender! There are ways to create wrappers for such classes which keep the vast majority of your code testable and loosely coupled. True story!
  8. 8.  Before DI  After DI  You’ll notice you use the “new” keyword a WHOLE lot less when using Dependency Injection.
  9. 9.  When I finally learned how to use dependency injection, I still had no clue WHY we were using it. All I knew was that some highly paid consultants said to do it, and that was that.  The two most important reasons to use “DI” (Dependency Injection):  Makes it super-mega-monster-easy to unit test code without insanely complicated setups.  Caveat: As long as you learn how to use mocks when unit testing. On Luxor, we use MOQ, which I would absolutely recommend.  Another popular mocking framework for .NET: NSubstitute  Promotes writing code where various services (aka ‘dependencies’) your code requires can be loosely coupled with your code.
  10. 10.  The container is at the very heart of your DI implementation.  Interfaces are mapped to concrete types, so that the container can provide the correct implementation when an interface is requested.  Containers typically allow you to specify the “lifetime” of any object it knows about. You can have a singleton, one instance per thread, and more.  Containers map views to viewModels in the MVVM design pattern (used in UWP, WPF, and Xamarin.Forms apps, for example).  The container is the thing that will new up all of your services, views, and viewModels as they are needed.
  11. 11.  The magic: When you need some service in a class, you just add the interface to its constructor, and the container magically will provide it!  No… SERIOUSLY. It’s kind of amazing!!
  12. 12.  How does the container know what concrete types to provide for your interfaces?  How does the container know which views go with which viewModels?  Answer: Registration!
  13. 13.  Notice that ALL of the constructor parameters are interface types.  When we discover we need a new service, we can just add it to the constructor, and our DI container takes care of injecting it (thanks to the registration).  Note: Yes, there might be a code smell of too many dependencies in this ViewModel, but that’s not important right now. 
  14. 14.  The ViewModel from the previous slide has SEVEN dependencies. That would be a TON of overhead if they were all concrete classes, and LOTS of integration concerns to worry about when it came to testing!  Instead, we just mock, mock, mock all our problems away!
  15. 15. Arrange Act Assert
  16. 16.  Infinitely easier (and possible!) unit testing of code.  Loosely coupled software.  While DI is complex, the alternative is even MORE complex!  Just ask for whatever services you want in a constructor, and your DI container will “make it so”!  No complications about whether a class is a singleton or not… You already took care of that when you registered the class with the container.  As long as the container knows about the interface and the concrete class you want to implement it with, you’re all set.  Swap out implementations of interfaces (demo mode, anyone??).