SymfonyLive London 2015

IoC (Inversión de Control) en aplicaciones PHP

Kacper Gunia  · 
PHP

Presentación

Vídeo

Transcripción

Extracto de la transcripción automática del vídeo realizada por YouTube.

thank you everyone for coming as Michelle said my name is Casper am I going to discuss various problems with inversion of control I'm going to also discuss what invention inversion of control is and what it isn't and in going to show you how we can

look at in from different perspectives so that's my Twitter handle if you if you want to follow me on twitter i'm technical team leader at century labs you can also trainer from time to time i'm a sinful and certified developer and i also co-founded

the meetup PHP meetups in Poland so that's about me and this talk is split into three three chapters the first chapter is about the theory depended of inversion of control and just at the very very beginning I would like to say one thing that this is not

yet another dependency injection talk I'm not going to talk about constructor injections and why you should do this and where your in and why when you should use centers and so on I'm not going to cover the basic stuff you say I'm going to talk

about it but it's from different perspective a bit so because of that we need a bit of clarification and the first thing that I want to clarify is that inversion of control is not just dependency injection why it's because inversion of control according

to the definition is a design pattern that addresses a components dependency resolution configurational lifecycle it suggests that the control of those free should not be the concern concern of the component itself so it just says that our code shouldn't

really care about its dependencies and it shouldn't care how they are instantiated words the lifestyle and so on we shouldn't care about it really and dependency injection is one of its incarnations so independence injections we say okay all our dependencies

are given by constructor by some metals or biofuel fuel injection so difference is that inversion of control is the general bit concept that says we shouldn't care about it dependency injection is the way of solving that problem and there are other ways

of solving that problem and there are actually three so one is dependency injection as we the other is AOP and the third one our event and I'm going to say in a second why I think these are the three ways of solving that problem but first in the very beginning

I would like to say why do we invert this controller or applications and water are the prawns just quickly we probably know all that so we don't want to care about the dependency dependency resolution configuration and so on we want to enforce the single

responsibility principle which says it's not that object or method or class has one responsibility it has one reason to change and what's important if we are writing our code and the way that some other object is created is changing and we have to

change it in our code it means we have two responsibilities because we are doing our thing and we are changing changing how the how the other object is created so there are two responsibilities and we were to get rid of that with basically we also want easier

testing and it's doing things right with inversion of control enables that but not always I'm going to show why and also we want to promote them onto modular architecture loose coupling and all the good things but what are the what are the downsides

what are the cons of this of this approach obviously there is a learning curve especially for new developers but that's that we can handle that we're smart guys but what's worse the code becomes harder to analyze small units are okay are fine but

our code is not longer linear it's not procedural we can just print a one page and read sort order it was happening there especially if we are using events so the inversion of control moves this complexity from our module somewhere else but it doesn't

remove it and it has to be solved in some way so we have like extra tools tools like containers dispatchers and so on so just to remind you how do you write software without inversion of control so we've got some simple interface that used files we've

got a logger that just echoes prints whatever and then we have our class so whenever we need the log we create an instance we lock which prints we unlink the file that's the example and that's it and then we use it in this way well we all know that

so these are the basics and with dependency injection it's quite obvious that we are probably going to this constructor injection then create this dependency outside and it's done it works in this way and if you think about it if you look at this code

what's happening here we our module our class we are in control what is being executed and when this thing is being executed so we are in full control and if you look at the chart it gives us in this position so we know that what and when are known and

that's one of the approaches to doing of doing the inversion of control so we can't were in control of everything obviously it adds adds some complexity door to our code but it also gives us the benefit that we can change it whenever we wanted so how

we can save the cell how you can solve the same problem with events so again i created a really simple implementation of observer so we have just some listeners so event then we have some file event something is happening with a file then just extension of

this then we have a logging file event listener so it gets the logger and when there is a file event happening here it just logs this so it basically does this exactly the same thing and then there is a dispatcher it's an important but what's important

in our in our case here is that our file irizar that's exactly the same thing just unlink the file but it doesn't really care how this thing how this logging is handled it decides when this thing is handled so it dispatches the event so it says hey

I'm going to do this but it doesn't do anything about it it's not aware that there is some logging logging happening and then again there is another even dispatched and we instantiate it config you configure the dispatcher and that's it so

on this chart positions us here that we know that something is being executed and we are in control when this thing is being executed because it's our class that's responsible for sending these events emitting these events but we don't know what's

happening so that's that's like this exactly that's exactly the same problem solved in two different ways that that are giving at two different levels of control of our dependencies so also there is a third thing which is AOP aspect-oriented programming

and i know that in PHP there is thing called go aop PHP which is like aop container but i'm not going to use it because it's going to be too complicated and i don't really like the idea itself i'm just talking about for the sake of being covering

the topic in one hundred percent so what we really want to do what's up responsibility automate responsibility of our class is to unlink the file here and that's the that's the purest form of our class so what we can do with aop is to implement

it using decorator so basically decorate it and that's maybe an overstatement but it's actually it is an implementation of aop so we have our file user here we are injecting decorating it and I think aspect before okay logger file was initialized than

calling the decorate decorated lager and then adding another aspect after all so we could add a trackage here and and do some add some other aspects as is described in aop but that's the implementation and then we just created this local for user then

[ ... ]

Nota: se han omitido las otras 3.792 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.