 Good evening everyone. Welcome to Drupalcon Vienna. Today we will be talking about this topic, demystifying dependency injection in Drupal 8. I am Jyoti Singh. I am working as a web developer in region technologies and today with me I have a co-speaker with me. I would like him to introduce himself. Thank you. Hello everyone. So myself, Yogan Prasad. I am working with region technologies for more than three years, having total more than five years of experience on Drupal only. So about me, I am Drupal developer at region technologies and an active community member for Drupal daily community. So today the topics we are going to have in the session is the problems we are facing in Drupal 7. The dependency injection, what is dependency injection, what are services and services container, Drupal 8 core services that we are using right now in Drupal 8 core and then using services in our contributed module. So today's session will be covering only these topics. So when we are coding, the first thing we want to have in our mind is we want to have a code like this. A very clean code wherein we want everything to be structured, well-maintained, easy to manage so that it's readable for the user and for other things. But what actually happens is something like this. A code looks like this. I am not a Drupal 7 person but I started with Drupal 8 but what I feel when I see Drupal 7 code is something like this. So some of the things that I asked my friends, the people who are actually working in Drupal 7 and something I found with Drupal 7 code were, we cannot reuse the code. So there's a fine line between reusing the code and overriding the code. What object-oriented programming specifically works on is reusing the code. But what Drupal 7 code we usually do is override. Whenever I want to have any contributed functionality to be in my code, I override it. So I think personally that Drupal 7 does not work on object-orientation thing. So that's a problem with Drupal 7. Another thing is testing. So when we say we want to create a unit test with the simple test module, we need to have the Drupal bootstrap so that we can use the core functionalities or some of the variables that we want, something like loading the node, something like that, because we don't have the whole control of the Drupal until we bootstrap it. So there's another problem with the testability that I found is in Drupal 7. Then what I told you there in the picture was a lot of cluttering is happening with the code. So where does the cluttering actually happen is there is excessive use of hooks that we are using in module file. So there's almost like 5,000 or 6,000 line of code in our module file. We have a lot of form alters. We have a lot of hook menus. We have a lot of hooks there in module file. Another thing is whenever we are writing a preprocessor, there is some or the other things related to calculation involved in that. So that's not a good coding practice at all. That's been practiced by most of the developer that are working in Drupal 7 actually. And another thing is in our template file there is PHP code. I see the eco PHP, a lot of printing and a lot of debugging with PHP code in template file. So these are creating a lot of problem when we see about the code reusability, optimization and other things that should be according to the standard of the code. So what is dependency injection? When I started Drupal 8, somebody asked me, there's a new concept that's going on, that is dependency injection. And they were like, they didn't have any idea about dependency injection. Everyone say we use dependency injection, but somebody asked me that what is dependency injection? Even me, I cannot code that into a simple phrase of words saying this is dependency injection. Because that is actually a really big concept that we are using in Drupal 8. And actually it's the symphony who bought this concept. So what is dependency injection? It is an advanced software design pattern. So the thing you are seeing right now is totally theoretical definition that is given by the Wikipedia. So that is advanced software design pattern. It is in version of code. It means reusability code call when we need to have a specific task code. But actually in a very lame word I would say, whenever you want your object to have specifically defined dependency, then you use dependency injection. In general term, whenever we have objects, it loads all in one creating a large bundle of dependency at one go. But with dependency injection, you have the flexibility to define your own services and own container and have your own dependency called. So what does it actually mean to the developer? So for me, whenever a developer asks what is dependency injection, I would say that it makes your code clutter free. It reduces the class coupling making it loosely coupled and increasing the code reusability since it's a very strong concept of object oriented programming. And it improves code maintainability. So these are point would be get reflected when we will be going out with the other slides of the presentation. And then other things are improving application testing as I already told you that unit testing is a problem. Unit testing is not that easy with Drupal 7 bootstrapping. And then there is also a centralized configuration associated with this. So the less you know your code, the more usable it is. That's the oops concept. So further moving on, my co-speaker would be giving information on it. Thank you. Thanks, Jyoti. So how things work? Let's get more deep into the dependency injection. So let's consider the piece of code where we have two classes, product and stock item. As you can see that there is a class product which will use the class stock item to calculate the stock current for the corresponding product. So what is here happening is that the product is directly calling the, directly initializing the object of the new stock item, the stock item class. So in this case, the product and the stock items are tightly coupled. So if in future we have to add any new argument to the stock item class, we have to make changes everywhere wherever we are using or initializing the object for the stock item. And similarly for in case of unit testing as Jyoti mentioned earlier, so if we want to unit test or perform unit test on the class product, so what will happen? We cannot perform a unit test on the product class independently, we have to perform a class test on stock item also because it's a dependent class. So for solving this problem, how can we solve this problem using dependency injection? So in major we have three types of dependency injection. Let's cover all of them by examples. So first of all we have constructor injection. In this case, as you can see, we have replaced the initialization by passing the dependency as an injection as an argument for the constructor. As the constructor for the product is getting an object of stock item class. Now if we change any argument for the stock item class, we do not need to change anything here also. And it will run as a unit test freely. We do not have to depend anymore on the stock item class. So we can just pass a unit testing demo and a unit testing object to this and we can run our test case freely. So what are the scenarios where we can use constructor injections? So suppose there is a scenario where you have created a class which required a required dependency. So your class cannot work without a dependency you need there. So in this case, as you can see in the example, you are passing the dependency as a constructor. So it will be mandatory to pass the dependency and it will be present all across the object or you can say across the object's lifetime. And the second advantage of constructor injection is that as the constructor functions only once in the lifetime of the object. So it is that the dependency can't be altered during the lifetime of the object. So these are the two plus points of using constructor injection. And this is the most common way of dependency injection we use nowadays. So there is one drawback or you can say limitation of where we cannot use the constructor injection. So suppose we have a class which do not require any required dependency. We just have an optional dependency. So in that case we cannot go with the constructor injection. So for solving that problem we have the second type called setter injection. In this case, what is happening is now we are passing the dependency injection as an argument but not for the constructor. It has been passing into the function itself. So in this case, we are not having a required constructor and we are just adding a new setter function and we can add multiple dependencies to our functions, to our class. So what are the positive points of using setter functions, setter injections? So it allows us to use optional dependencies so that we can have multiple dependencies in our class. And it is very easy to use as it doesn't require to change our whole code to just add a new dependency in our class. After that we have a third type of dependency, property injection. So in this case, we just add the injection as a property of the class. So in this case you can see that we have a property called stock item of the product class and we are using the stock item to replace the value. So what are the negatives? This is the most rare use type of property injection and what are the negative scenarios we have with this? So in this case, we are not have control on the dependency object. So as it is passed as a property of the class, we can alter, we can change the value or we can change the dependency anywhere in any point in the object lifetime. And one major thing we cannot use with this type of dependency injection is we cannot use type hinting, which will not make sure to us that the value we are getting is a object or whatever it can be changed in a midway of the object lifetime. So we are not confirmed what is the type of the dependency we are getting. So for overcoming that, we have to add an explicit test that the dependency is of R type only. So is the dependency injection is right for my application? This is the major question as a developer we have. So according to me if you are working on a small project, I think it may be a overkill to use dependency injection as it requires more effort and more understanding about the dependencies. But if you are working on a large product which may have extension in the future and a long running project, then there is a big chance we can use dependency injection and it will be a good solution for our project also. That's it. Thank you, Jyothi. Thank you again. So moving on next, we are going to discuss about what are services and services container. So services and services container is the new topic that we have in Drupal 8 and dependency injection is what introduces services and services container. Dependency injection is the preferred way in which we implement services and services container. So what service actually is? Services is something when you want to request a specific object to create your functionality. So service is an object usually with some instances and you define some dependency with it and the services you want is there. So a small analogy for understanding services is when we have a set up box and we want some of the services to be there in it like we request for HBO, we request for Netflix service. So what service provider does is if you subscribe the service with your service box. So we are not concerned about the set up box whether it is Apple, whether it is some other company and we are not even concerned about the service provider. What we are concerned is having the services. So basically service container is like a set up box wherein you have a set of services defined already and when you request for a service it is through dependency injection. So there are a few examples in Drupal 8 code that actually uses services is like when we have to send emails, when we are using loggers and others. So next we have is the core services in Drupal 8. I have a list of core services that are being used frequently in Drupal 8. So those are entity.query and entity.manager, then config.factory and config storage. So config.query and entity manager are the services that provide an interface to the entity manager services. So without statically calling the entity manager functions that creates an overloading for Drupal, we simply use services. That is an object oriented approach of using the services. Then when we talk about config.factory, that is the service for config manager. So rather than call it statically again, we can define services in our class itself. Then similarly we have config storage that defines the storage for your entity and the configuration that can also be accessible through services. Other we have config.type, even dispatcher and current user. These are also part of the services and can be used frequently with the code. So here is an example where I am using an entity manager service. So I have created a create function in my class that gets the container from an entity manager and I am using it to load a node. So this is how we actually access the service through services. So I will be showing a quick demo on as to how I have used it in my custom module for services. So this is my module and this is a structure for Drupal 8 module and the services we actually define is in the module.services.yml file. So this is a very simple service that has been created for updating the time stamp, for getting the time stamp and here under the services keyword, we define our service name and we define the path for the class of our services. And here is another keyword argument wherein we can pass the argument for the services. So even for the argument to see the services that has been provided by Drupal core, we can go to the file code.services.yml and see the list of all the core services that has been provided by Drupal. For Drupal user, we can have cache context user.rolls. These are for the cache context tags and other services that are defined in code.services.yml. So in my module, I have defined the services here and that can be used anywhere in my class. So another thing that we associated with services service tags, whenever we want to categorize a service into a specific subcategory, we use tag. That eases the Drupal to understand which category the service actually falls into. So some of the tags that we usually use is event subscriber, event access check and cache.bin. So event subscriber is actually being used by the core for some of the things like redirection, access per URL. So when I go to the score.services.yml file, I can see the tags here. So under this section tags name, there is event underscore subscriber wherein I can define that my service belong to event subscriber. There are many other examples also wherein we can define the tags to which there are services belong. There's the same code.services.yml. That's it. Thank you. Any questions? I guess I grabbed it quickly. Sorry. Hi, can you go back to the property injection slide? Yeah. Yeah, I don't see the difference with the two last lines. I don't understand them. You set the new object and then you use the one provided as an argument. Set stock item. Yes. Inside the set stock item function. Yes. Yeah, I see that stock item received a new object. Yes. Then afterwards you use the one provided as an argument. I mean, what's the difference? I mean, yeah. Yeah, so actually, we were working across this property injection type. So we didn't able to work it around. So as of now, we can have a better example for this if you want. Yeah, I would be glad to. Thank you for the solution. Any other questions? Any other questions? Thank you. Thank you.