Presentación
HTML (pincha para descargar)
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
I'm so so grateful to be here really I think I still can't believe that angular has you know its own conference it's it's crazy so thanks for coming and thanks for making all this happen you know and I don't mean just the the conference
but this whole ng universe or something like I have no idea how it happened but it's pretty amazing I would like to I would like to show you something I've been working on recently a new dependency injection framework something you might be using in
the future version of angular so I've heard it's good practice to start with why so I have two questions that I thought you might ask me first one is why do we like the balance injection so much the second one is ah why are we creating yet another
di framework so let's start with the first question why are we that crazy about this thing called dependency injection you know why is it so important in core piece in angular well in order to answer this question I want to split the term dependency injection
into two parts where the first part is di as a design pattern and the second part is di as a framework look at this code a coffeemaker and it has three dependencies is Grindr a pump and heater now this is not an example of the design pattern that I'm talking
about because this coffeemaker is very tightly coupled to this particle environment if you want to instantiate the coffeemaker you need to make sure that you know there is a grinder constructor that there is pump it get instance and that there is some global
app contacts with get method which will give you the heater so how can we make this better we can refactor this to something like this this is it this is basically the design pattern that I'm talking about you know all the dependencies are simply passed
in as constructor arguments and this coffeemaker has no idea where these dependencies are coming from so it's much easier to reuse this code you can be you know it's much easier to instantiate it in a different environment now the whole testability
is all about just you know being able to simply instantiate small parts of your app and I mean think about it how would you test this coffeemaker you know how like when you when you want to test this coffeemaker what you want to do is instantiate it many times
in kind of different environment like in the different configuration and to make sure that it works at all these scenarios right you see where this is going to basically testing and reusing the code it's the same thing you know that's why that's
why testable code leads to a reusable code because it's essentially the same thing and that's why we like this design pattern that's why we what we use it so much because it makes our life easier now it turns out when you follow this design pattern
you end up with something like this a main method where you instantiate all of your objects and you kind of wire them together you know this simple example the dependency of this simple app the dependency graph looks something like this it's very simple
is coffeemaker the requires pump and either and Grindr and if you look at this imperative main method it basically oops I want to do this it basically can encode this dependency graph it's kind of encoded in this imperative code now the problem with this
is that you have to maintain it okay so anytime you want to add the new dependency or split up object you have to maintain this main method so for instance the concrete example let's say we want to add a logger into this simple app obviously we will go
to coffee maker and you know use the logger locked something but then you need to go to this main method and add the logger and wire it up or maybe a better example imagine you guys building an angular app so you start with a single controller and you kind
of put everything into this single controller I mean that's how everybody starts right and then at some point this controller is actually pretty big and also there is probably some functionally that you want to reuse somewhere else so what are you going
[ ... ]
Nota: se han omitido las otras 2.066 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.