 Now, if you had the Pokemon ringtone, that would be fine. I don't know the song. Do you know the song? I think you should sing it. I feel like I could find it on YouTube, but, like, cool. It's 1045, so I guess I should get started. Welcome to OOP, The Pokemon Journey. If you don't already know, this is a beginner backend session. We're going to learn a little bit of code, but we're going to do it in a really fun way. I think it's going to be great. I hope you enjoy it, and feel free to give me feedback afterwards. So let's get started. My name is Fatima. You might know me as Sugar Overflow. That's a really great picture of me. I work at Digital Kidna, the Red jerseys, where a digital services company in London, Canada. We do a lot of Drupal, and I'm also on the leadership board for Drupal Diversity and Inclusion. And if you haven't already, please come to our booth and get your picture taken. A couple of people filing in, but I'm just going to get started. Today, we're going to learn object-oriented programming from the perspective of Pokemon. We're going to go on this journey to become the best Pokemon trainers ever, and on the way, we're just going to let her learn a little bit of code. All Pokemon journeys begin with visiting Professor Oak at his lab, where we get to pick our starter Pokemon, which is the Pikachu. As we start our journey, we're like, hey, Pikachu is a Pokemon, but what is Pikachu and what can it do? We'll take a look at our first Pokemon and do a little data modeling We know that its name is Pikachu and its type is electric and its attack is called a Thunderbolt. So this kind of tells us that, hey, we have some data points about this thing that's a Pokemon, and those data points are the type and that it has an attack. We have this thing and it's got data points, but how do we take this data and model it into code? OOP gives us this really cool concept called classes that allows us to do this. These are like blueprints. There are two components of classes. One of the components is properties. I like to think of properties as data points, something like the type of our Pokemon or the name of our Pokemon. Classes also have methods. You can think of them as class-specific functions. These are things that your class can do. For example, Pikachu can attack. So now that we're talking about what classes are, we can go ahead and define a Pokemon class. I'm going to take a break and let you look at that slide for a bit. If you have questions on the way, feel free to raise your hand and interrupt me and create our Pokemon class. When you first start making a class, is that too small in the back? No? It's good? Okay, awesome. When you start making a class, you use the class keyword. Here we have class and the name of our class is Pokemon. We've added two of our data points, which is the name of our Pokemon and the type of our Pokemon. There's one more data point if you remember, and that's that the Pokemon has a method, the attack function. We're going to go ahead and add that. There you'll see the function keyword indicates that attack is a function of this class. For now, it's just doing something and returning a class. A function sort of can return things, doesn't always have to return things, can sometimes do things for you to help you, and sometimes can pass in parameters as well. Now that we have this Pokemon class, with really basic properties and an attack function, we meet one more thing to create an actual Pokemon. That's something really special called a constructor. We like to call this a magic method that PHP provides for us. The constructor lets us create objects of a class, and when I say object, I mean an instance of that class. You have this class that builds this thing called Pokemon for you, which has properties and functions, and you would call that an object of your Pokemon class, or you'd be instantiating your Pokemon class. If you take a look at the last part of that code snippet, we put in our constructor, we passed in our name and type variables, and we initialized them to the ones that are in the class. I tend to talk fast. I'm just going to take a break, enjoy the silence, let you look at the code. Class is kind of like the blueprint. When we do that, we do that when we actually create the object of the class, which is why we've passed the name and the type into the constructor, which means when I'm going to create a Pokemon, I will give you a name and a type for you to fill in into your Pokemon object. Are there questions? Now that we have our class and we have this magic method constructor, we're going to go ahead and create an actual Pokemon object. Just as a recap, our constructor takes two parameters, the name and the type. We're going to use something called the new keyword, and it's basically saying, here's the Pikachu valuable, here's the new keyword, create a new Pokemon, which is the name of our class, and we have to pass in the name, which is Pikachu, and the type, which is electric, and this essentially creates a Pikachu for us. If we want to go one step further and remember that we had an attack function in this class, we can then use our Pikachu variable and call the attack function using this arrow syntax. This is the constructor, takes a name and a type. If you want to create an object for that class, you use the new keyword, you pass in the name and a type, and then when you want to call a method from that class, you can call the method from the object that you created. Just to make this a little bit more real, we're going to look at an example in Drupal Core to kind of cement the concept and also give you something that's familiar that you can look at when you're doing your projects. An example of a class in Drupal Core that I picked out was the link class, and we're going to be looking at most of the code, but if we can focus on the constructor for the link class, you pass in a text and a URL object called URL. Don't have to worry too much about the URL object, we'll just focus on what the constructor is doing and that it's setting the text and the URL variables within the class. And then we'll look at a place in Core where this link constructor is actually used to create a link object that's used in this abstract class entity in this abstract class entities to link function. We'll add a stuff to the variables that are passed in, and then it returns a new link object and passes in the text and the URL that the link constructor needs to create a new link object. Oh, I see someone nodding. So, we've been traveling for a while with our Pikachu now, we're going to get back on the road, we're in the forest and suddenly a wild Pokemon appears and it's an Oddish. And of course, you have a Pikachu, you have to do battle, you need this Oddish. So we do battle, we get this Oddish, and we're like, wait, what's an Oddish? We only have a Pikachu. So we're going to take a moment and be like, what's an Oddish? What does an Oddish have as data points? How is an Oddish different from a Pikachu? So if we look at our Pokemon now, we have the Pikachu that we already had with the electric type and the attack of Thunderbolt, and then we have an Oddish, which is a grass type and has an attack of poison fire. So it's already quite obvious to us that there are different types that we're going to encounter on our journey. And there is a Pokemon concept for this and we call it inheritance. Inheritance is about sharing. Generally inheritance, you have a parent class and a child class that inherits functionality from that parent class and can also override functionality that you get from that parent class. In our case, for example, we'll get to that. Sorry, I skipped ahead. So this is inheritance. There's a certain amount of things. There's a child class that can inherit all of those things and then also define its own things and be unique in that way, but also override things that its parents had defined. And PHP is also single inheritance, which means one class can only inherit from one other class at a time. But that doesn't mean you can't do class inherits from a class that inherits from a class that inherits from class inheritance exception. So you could kind of do that too. But just as kind of a reminder, you inherit from one class at a time. So now we're going to look at some Pokémon inheritance. So if you remember, this is our class Pokémon. It's got those properties that we set and that attack function and the constructor, just as kind of a recap. And then if we want to extend this class with our electric Pokémon class, which we've decided that now we're going to have type classes for our Pokémon to kind of differentiate between the different types of Pokémon that we'll find. So we're going to create a class electric Pokémon. We use the extends keyword to explain that this class is inheriting from the class that's after it. So in this case, class electric Pokémon is extending the Pokémon class, which means it's absorbing everything that we see up there and then can define more things or override things. We can go one step further here and take our electric Pokémon class which extends the Pokémon class. We can define the type variable to be electric and then we can extend it with a Pikachu class. In which we can now change the name variable to Pikachu and in the attack function, we can actually return the attack that Pikachu has, which is Thunderbolt. And in this way, we've overridden the attack function that we inherited from the electric Pokémon, which inherited it from the Pokémon class. That's a little cute. And then what's really cool about this, if we want to go ahead and now we'll create a Pikachu object, it'll look something like this. It'll look like a Pikachu new Pikachu. And when we do the attack function, it'll return Thunderbolt because the Pikachu class has overridden the attack function for the Pokémon class and actually returns a string that says Thunderbolt now. And then we'll go back to Drupal Core to look at an example of inheritance. The one I picked here is the widget interface. Don't worry too much about the words interface. We'll cover that a little later. What we'll focus on here is that this interface has this function called form element. And then this interface is implemented by the next class on the next line called widget base. And then widget base is extended by a class called range widget. So essentially it's another hierarchy that's passing all the way down. And class range widget then implements the form element function that came all the way from the widget interface and gives it a form element that has a two and a front because it's a range widget. And so I thought this was a really great example of how we can do things and then override them. Then I want to cover about inheritance and that's visibility. So in PHP we have different types of visibility. Public, protected and private. Public visibility means that things that are declared public in a class are accessible excuse me anywhere. And things that are declared public are accessed only within the class itself and the things that are inheriting from the class. So if something was protected in our Pokémon class our electric Pokémon class would be able to access those protected variables. But things that are private are only able to be accessed by the class itself. So when we talk about inheritance we say that classes, child classes of parent classes only child classes that extend parent classes only inherit the public or protected properties of their parent class. So if there's something private in your parent class it likely won't be accessible from your child class. I forgot to turn on notifications so I just got a message. So I got distracted. So visibility, super cool. Yes. Yes. So if you have a protected method in your parent class you can access that from your child class but if there's a private one you won't be able to use or override that from your child class. Thanks. Now that we've covered inheritance and visibility we're going to go back on the road and check in with our Pokémon and we're visiting this new town in Pikachu and suddenly we get challenged to a gym battle and this is our first gym battle and we don't do it really well because we're like because you go and they're thundershock and we don't really think about strategy or anything like that. So unfortunately we lose our battle but that's okay because lessons learned and there's always room for improvement and we learn from our battle at Giovanni that Pokémon have different types of attacks and different types can have different advantages or strengths and weaknesses and maybe we should be more strategic about how to use the throw into battle. So from this battle we've learned that Pokémon can have a strength and a weakness. We're going to have to update our data model. So we have a Pikachu and an Oddish type and attacks are there as they were before but now we've got strengths and weaknesses defined. So the Pikachu has a strength against water type while the Oddish also has a strength against water type and the Pikachu has a weakness against ground type and the Oddish against fire so that'll kind of help us strategize when we're doing battles in the future how do we update our Pokémon classes our Pokémon class now to model some of the new information that we've learned we'll do that with getters and setters. So this is our Pokémon class I've kind of commented out some stuff to make space but the properties, the constructor and the attack method are all still there I've added two functions you'll see one is a getter which is the get weakness function it'll return the weakness of this Pokémon and the other is a setter it'll set the strength for this Pokémon so you can see that the setter takes in a variable and then sets it to the member variable in the class generally it's best practice to use getters and setters with your object rather than try to access stuff directly from the object and then we'll look at getters and setters with inheritance because we have our electric Pokémon class which extends our Pokémon class and in here we're going to set the strength of the Pokémon according to its type and then it has other properties and method and then since we're doing class Pikachu which extends from the electric Pokémon class we aren't defining those getters and setters but because they're in the class the parent Pokémon class we do have access to them so if we do something like creating a new Pikachu object and get weakness it'll return the weakness that we've set in one of the parent classes and look at some getters and setters in Drupal Core the example I picked was from the RouteMatch class which implements the RouteMatch interface in this class they have a function called getParameter which I use quite often and what it does is it returns the parameters so RouteMatch helps you get the routes that are a part of the URL on a page so getParameter will tell you what parameters are in that URL string on the page that you're on and the way that they do this is they load the service which is RouteMatch and don't worry about that too much but then they call the getParameters function from the RouteMatch service and they call the method on that so that's like an example of a getter in a Drupal class in a class that's in Drupal Core I'm going to take a quick recap because I know we've been kind of spinning through inheritance quite fast we have a class Pokémon and then we have a class Electric Pokémon which extends the parent Pokémon class and then we have a class Pikachu which extends the Electric Pokémon class which means we can do both of these things so there is us creating a new Pokémon passing in a name and a type as Pikachu and Electric and then calling the attack method on that Pokémon but since that Pokémon is a Pokémon type it's calling that generic attack method from the Pokémon parent class which doesn't really know what Pikachu's actual attack is and we can also go ahead and create a Pikachu and call the attack method and since the Pikachu extends the Electric Pokémon class it already knows that it's Electric and it knows that it's Pikachu and what it also does is return that Thunderbolt attack which is specific to Pikachu so when we're looking at this code here I was thinking we don't want to create generic Pokémon anymore we have typed Pokémon we have classes for specific Pokémon so how can we still keep the functionality that we have in that parent Pokémon class and be able to create multiple types of Pokémon but not be able to create this generic Pokémon object because we're too much data way too much data and OP gives us a way of doing this called interfaces interfaces are like contracts so it's kind of code that specifies that a class must implement everything that's in the code it's kind of like a contract so you have to agree to certain rules everything in the interface is public and the class has to implement that's everything in there so in our case our Pokémon class will be our interface also you can't instantiate an interface so you can't create a type of an interface you have to implement it in a class and then you can create an object of that class so we'll look at that with Pokémon first we'll take a look at our interface for Pokémon and I've thrown in a couple of Pokémon methods in there like set the Pokémon name the attack method that we looked at before the get strength method all these methods are public and you'll notice something weird that they don't actually have any bodies defined they don't do anything and that's because this is an interface so how do we use this interface? I'm just putting that there with just one method so that you remember what it looks like and then in our class Electric Pokémon we use the implements keyword to signify that we're going to implement the Pokémon interface and in our Electric Pokémon class we've defined the type to be electric and we'll take that get Pokémon type from the Pokémon interface and give it some functionality which is returning the type just for now so we can go one step forward and in our Pikachu class which is extending the Electric Pokémon class which is implementing the Pokémon interface we can take that get Pokémon type and also return a type so you can do it in either so now that we have this Pokémon interface we can't go ahead and create generic Pokémon but then that makes us think do we want to create generic electric Pokémon? because we have Pikachu as a class because that's kind of weird too because if we're going to have more electric Pokémon on our travels we might as well create classes for them too so for the Pokémon interface we wanted to keep a functionality that could be like a parent class but we didn't have to instantiate it for the Electric Pokémon class there's also a way to make this so that it's sort of functionality that we can use but we can't necessarily create an object of and we call that an abstract class an abstract class is kind of like a skeleton it provides you some functionality and it's commonly used as a base class for things but it can never be instantiated which is perfectly for us for our Electric Pokémon class cool someone nodded this was the last minute edition cool we're going to look at our abstract Electric Pokémon class just a recap on our interface we have that get Pokémon type function defined in it and here's our Electric Pokémon class you'll see that I've added the abstract keyword before the class and you'll find that this class is in fact abstract and in that abstract class in the get Pokémon type function I'm returning electric as the type of the Pokémon and then in our Pikachu class which extends Electric Pokémon we're kind of inheriting that get Pokémon type function so when we create a Pikachu object and we call get Pokémon type it's going to return electric yes so the abstract class can define the bodies of methods but the interface can only give you the function definition like just the function names so the interface is like everything that's in here it's only methods it's all public you have to implement it whereas the abstract class is a little more flexible it can give you things like in this case the Electric Pokémon class is abstract but it's kind of doing the work for you so when you extend it you kind of just use what's implemented in that function so it's got like method bodies I don't think so I think you always implement an interface but it could be wrong can you extend an interface? oh I got a thumbs up is that a yes? you can? maybe that's out of scope for a beginner session extending an interface and all the other weird things OOP lets you do that maybe you shouldn't be able to do yes I have in my notes woohoo inheritance interface is an abstract class all on the same slide it only gets easier okay we're going to go ahead and look at an example in Drupal Core that I really like it's the form interface it implements this function called get form ID and then in the form base class which is an abstract class it implements the form interface and then when you're creating a custom form or you're looking at forms in Drupal Core like user login they generally extend form base because that's the base class for forms and they implement the function that was being passed from the interface so form base signed this contract and user login form implemented it and gave it's ID for the form and I make a lot of custom forms so I'm sure there's stuff in it for the sake of the code on the slide I only kind of focused on so the form interface provides a lot of functions and the form base class also provides a lot of really useful functionality but for the sake of the code I wanted to focus specifically on the get form ID function and show how that kind of travels through the inheritance into your custom form for recording so what he was saying was that one of the things that the form base class actually provides for you which is really great is the validate and submit handlers and they'll kind of do that work for you so you don't have to write your own submit handler when you submit the form unless you want to do special things which is usually always we're going to go back to our story is everyone kind of clear on this it gets easier as you do it more so I would encourage you to just kind of dive in so we're back in our story and all of a sudden, you know, we're at this lake and our is evolving into a Charizard but now we have to update our data model so we know that not all Pokémon can evolve and so we can add that to the interface and some Pokémon evolve in different ways sometimes you give them a special stone sometimes you did really well and they're happy and they want to grow and so that depends on, you know, the exact Pokémon and not necessarily the type so how do we model this ability to evolve without putting it in our base class or in our interface PHP gives us this really cool ability called traits I did a funny before we get to traits this was the data model slide that I didn't finish but you have a chameleon and a Charizard the one on the left evolves to the one on the right and how do we model that in our base class since all Pokémon don't evolve we use traits traits are like code snippets we call them code copy-pasta it's a form of code reuse that doesn't involve inheritance and it kind of, you know, gives you another way to bring some code into your class and to bring it into any class, essentially it cannot be instantiated so you can't create an object of a trait you can't do, like, a new trait, something but you can use a trait in your class and then you have access to all the functionality that your trait is providing so we're going to go ahead and do that first we're going to create our own trait a Poke Evolution trait and in there we're going to add this evolve function which returns a new object according to something that we're passing called a next stage in our Charameleon I actually don't know how to say that Charameleon Pokémon class which extends Fire Pokémon class we're going to do the use keyword which means we're going to use this trait in this class so it says use Poke Evolution trait which means we're getting all the functionality from the Poke Evolution trait that we defined and we're also defining something called next stage which is a property of this Charameleon class and we're setting that to Charizard so and the class Charizard also extends the Fire Pokémon class so when we want to create a Charameleon we do the new keyword we use the Charameleon but when we call the evolve function on our Charameleon some magic happens so the first thing that happens is that we create this Charameleon and we've set the next stage variable in the Charameleon class to Charizard so Charameleon knows my next stage of evolution is a Charizard and we're using the Poke Evolution trait which provides the evolve method for us and the evolve method returns a new object according to itself and to the next stage so we're telling it my next stage is Charizard and then we're returning a Charizard yes you would it's not being mapped to an object right now yes so the second line of the code there if you actually want your Charizard object you would do Charizard variable equals Charameleon evolve I guess I didn't cover namespaces but if they were on the same namespace I guess you could use it and if it wasn't then you would have to put the use definition in the top of your class yes you just have to include it at the top of the file yeah it's kind of like a file of its own yeah it's like a poke evolution trait.php cool we're going to go ahead and look at an example of traits in Drupal a really popular one or one that you use and maybe you don't know it comes from a trait is the string translation trait which has a t function and this t function returns a new translatable markup with a lot of cool stuff in it and that's used in the plugin class and the way it's used is use string translation trait it uses the use keyword to use the functionality from the string translation trait which means when you go ahead and create a plugin or when you extend an existing plugin which extends plugin base you're getting that t function to have translatable markup so if you've ever used the t function it's kind of coming from another place which is a trait my code says much wow I think I left that in there to stay relaxed that's great now I always think sometimes they should have conferences with at least one session room that has sofas instead of chairs so people can just be like chill and then the speaker can be like yeah everyone's chill everything's great it's just like long cedar sofas they have those old hotels that have long cedar sofas so we're about to dive into some interesting stuff now feel free to ask questions at any point this is going to be fun so we go back to our journey and something exciting happens oh question rather than a method so the reason specifically in our pokemon example the reason that we're using the evolution trait here is because I have different pokemon classes and if I were to create a method I would have to create it in the electric pokemon class in the fire pokemon class and in our specific story evolution doesn't depend on the type it depends on specifically the Pikachu or specifically the Charizard and how they evolve also depends on the pokemon so if we put that method in our parent classes we kind of have to use it in all the classes that extend them and they might not necessarily need to evolve so a trait is an example of a thing that you might only have to use in very small cases and doesn't apply to all of the things and so it it kind of lets you plug something in without forcing everyone else to use it as well yes, that is one one sort of explanation for why to use traits is just you can avoid inheritance and unfortunately it's single inheritance so here's some copy pasta oh no I spoiled it I think exciting happened on our journey and we won our first badge and it kind of looks like a droopal badge so now that we've won badges we're like oh no we have to model this in our code and we need to have a system that lets us earn badges and badges system is another functionality that can change because different badges have different requirements and so something in OOP that lets us implement this kind of thing which is a system and that has different requirements and different types are called plugins and plugins are like functional Lego blocks and kind of just use them there are many different types of plugins and there are many different types of existing plugins in Drupal there's I think of plugins as there's a bunch of different behaviors they can do but they're in a common interface and not interface in the sense of the interfaces that we've talked about but interface in the sense of English language so there's a thing, they all work kind of differently but they all kind of look the same that common interface so in Drupal there's many existing types of plugins there's annotated plugins, YAML plugins for like menus, hook and discovery plugins and generally I think you would extend an existing plugin to do some work so you know making a custom plugin takes a lot of work you have to like create all these fancy things like a plugin manager and a plugin interface and your own custom plugin base so if we go down this route of creating a Drupal badge plugin for beginner sessions so we're going to shift gears a little bit here and maybe do a mixture of Drupal and Pokemon at the same time it's like a crossover so if you get confused feel free to ask questions so instead of creating a custom plugin we're going to extend an existing plugin and the one that I've selected is the block base plugin which is the base class plugin for when you create a custom block a block is what we call an annotation type it's a type of plugin which is called an annotation plugin an annotation is that fancy looking comment that's right above the class definition it's this key value structure that defines what that plugin does for example where it says at block it's telling you it's telling Drupal this is a block plugin and we can go more detail into what goes into the class but for now we're focusing on this idea that blocks are annotation which is a type of plugin that Drupal provides and here we're going to make a profile block for our Pokemon so we're kind of shifting gears and thinking more about websites now so placing a block on your website about your Pokemon coming out of the abstraction a little to understand plugins annotation based plugins are great because they let you do a lot of complex things in the annotation you can indicate which strings can be translated when discovering plugins so we're going to take a closer look into our Pokemon profile block so in our Pokemon profile block which extends block base we're doing some fancy stuff with a container and we're returning in our build function and we're returning a render array we don't have to worry about that too much it's just that there's a build function that comes from block base that lets us put things in our block that's what we're doing here and we did this because creating custom plugins is a lot of work and maybe not a beginner thing so we're just going to extend an existing plugin which is block base and we created a Pokemon profile block does that make sense? annotations do magic for you sometimes so where we saw that annotation and I'll go back a slide that says at block says hey Drupal we have a block here so when you go to structure block layout there's a block in your list of blocks now even if it went 22 I don't know when this session ends we go back to our story we won a lot of battles and a lot of fame and someone comes up to us that says you should compete in the leagues and you're like the leagues why would I compete in the leagues to be the very best and so before you can join the competition though you need to submit your trainer profile and your trainer profile includes statistics about your Pokemon your power levels are and let's just say that the Pokemon world has been doing you a favor and storing them in a database and all you have to do is access them so OOP provides us a functionality for retrieving things in a pluggable way and we call those services I think of services as swappable operations you have same functionalities but you can implement them in different ways so it's same function but swappable code you can have two services that do the same thing but are different services so you can swap them out whenever you want they're globally available so you can use them in any class and there's usually an interface that defines those methods for the service and some examples would be accessing a database, sending an email or translating interface text not to slam the bottle into the mic go go go go we're gonna go ahead and look at our Pokemon interface I mean we're gonna go look at the interface for our Pokemon data service it's generally good practice that when you're defining a new service you should first define an interface for it so in our interface we define a function called get your least stats which takes a Pokemon interface object or Pokemon and an integer for the year that it is and then we go ahead and create our service it's class PokeDataService it implements that PokeData interface and then provides the method functionality for that get your least stats method we're gonna use just some magic query stuff for now and returns an array of data and how do we use this service we go ahead and create a Pikachu and then we load the service by creating a variable called PokeDataHelper and if you look at the syntax with the slashDrupalService that's basically the call I want to call a global service and I pass in the ID of that service and now if we want to call a method from the service we go to the URL syntax and we call get your least get your least stats and we pass in our Pikachu and the year that we want the data for we're gonna take a look at some services in Drupal Drupal Core provides a lot of services that you can use you can see all of them in the coreServices.yaml file one of them in there they find is the current user service which comes from the account proxy class and if you want to use the current user service you do something like this and then you put in the ID of the service which is current user and then you can access something from the current user object is everyone still with me symphony symphony is why they're called services are annotations PHP or is that a symphony construct I don't know but maybe someone here knows neither I use call the audience it's a plug into symphony as well yes one at a time as far as I'm aware I guess if you wanted to load more services you would give each of them like a variable so for example here you're doing current user variable is holding the service that you're bringing in so if you wanted to use multiple services it would be best to have a variable for each of them so that you can access each of their methods separately which is why I wanted to take a break and be like is everyone still with me is it about to get crazy just kidding it's gonna be great they're lazy load they're globally available and they don't take up a lot of memory only when you use them is when they use up memory pro tips alright so we're gonna move on I keep saying this like we're loading the service globally but there is another way to load our services and that's dependency injection so when possible you want to inject your services you can pass them in as an argument to your constructor or you can use setter methods to load those containers rather than calling that global services it's better to load services into your class and then use them that way many of the controller and plugin classes that core provides uses this pattern so if you ever go into those if you ever dig into core you'll kind of see really good examples of this do you remember our Pokemon profile info block and we were using and now we're gonna go ahead and inject our Pokemon data service Pokemon info profile block so here's our Pokemon profile block the first step to do dependency injection is to extend this fancy thing called container factory plugin interface you can copy paste it from another thing and the key to making plugins to use dependency injection is to implement that because that gives us a lot of functionality to inject our services so when plugins are created the code first checks hey are you implementing this container factory plugin interface and if so it gives you these two special functions or methods called create and then looks for your constructor so first we're gonna implement our constructor in which we're passing in our poke data interface which is our service, the poke data service and then we're initializing it in the constructor so we're implementing the container factory plugin interface and then in our constructor we're initializing our poke data service and then in this create function which the container factory plugin interface provides for us we're getting the poke data service from the container and now anywhere in our class we can use this poke data service variable and have access to all of the methods that were in our service so essentially in these three steps we have injected our service into our class I'm gonna try to repeat your question first is it by implementing the container factory plugin interface that Drupal knows to go to the create function to get the service from the container to create the object for the service rather than just creating a new okay I think it knows because it implements the container factory service but yes people are nodding so yes when you implement the container factory plugin interface Drupal knows that there's going to be a create function that's going to get that service from the container for you question he said what is the container do you also want to give me the answer I kind of know but I don't know how to put it in words in a way that I don't want to scare people away so how would you describe a container ELI 5 explain it to me like I'm 5 container is a thing it's a bucket that Drupal provides you can get all the services in it and you can get services from it a box of toys that's what the container is awesome okay so the container can only does only spin up one copy of the service and just keeps track of that service for you so a box of toys has a lot of toys in there toys are services and you can get them when you need them so this depends on the injection and that's all I've got the adventure continues I've only covered the sort of surface of but as you do more back-end work and as you do more code you'll kind of interact with new things and discover new things and I would encourage you not to be afraid because if you could do it with Pokemon you could do it for your client, for custom forms and each of you has the potential to write back-end code I know you do because I'm up here and I do so we're all in this together I hope this session provides a foundation for the basics and kind of helps you form ideas when you're facing new challenging concepts and let's all be awesome programmers I wish I could give everyone a Drupal badge like the one we got in that picture but I can't, but I can give you the slides and that's the bitly to the slides keep in touch with me I'm sugar overflow on everything and a special thank you to Kotzer for mentoring me on these slides and really helping me figure out how to get the subtraction into a way that could help people understand and feel more comfortable about back-end concepts Questions could create a custom block and then be like hey, maybe I want to put some special things in my block and then take that build function and go wild and then maybe find a service use the current user stuff and be like I want to display the current user's name, age and email in my custom block and start there and start to sort of expand on that if you're not a block fan create a custom form you're also extending a base class and then put some fancy things into your form plug for the examples module so PHP storm is one of those IDs and others also have this intelligent sense that when you click on a class that you're extending you can kind of travel through the inheritance or implementations to see where those functions are coming from and that's really useful for beginners because you can kind of see where the errors are coming from or you can see what other functionality that base class provides for you that you don't have to write yourself if you have sublime text you can do control shift P and start typing things in and when you type in interface it's like all the interfaces for your fuzzy search so that's what I did when I was doing this I just like control F the core folder and we were like looking for somewhere where a link was created control F for new link parentheses and then we're like does this one make sense oh this one kind of makes, okay and that's kind of how we found those core examples question I learned on DrupalizeMe I know it's not free so it's maybe not a resource for everyone I know Code Academy that does the interactive code tutorials has one on PHP that goes quite in depth into extending things and interfaces so that might be useful but for very very specific Drupalee and symphony things I would go to DrupalizeMe they also have this really great page they call unraveling Drupal8 plugins where they use the example of an ice cream factory and they teach you how to make a custom plugin which I didn't want to talk about because it was too complicated but that's a great read and it's got a lot of pictures so plug for Drupal console if you type in a command it builds a module for you check your local library because they will probably want to teach you programming can we take one from like back here with everyone in the picture yes any other questions sorry? I haven't mentioned namespaces no I guess if you want me to explain namespaces on demand how would I explain namespaces? it's a thing that holds the code that you create and owns it that's a lot like folders yes, namespaces are like folders I will add that slide namespaces are like folders if you're in that folder you can call things that are in that namespace or folder and if you're not then you have to use the namespace at the top of your class so there's a lot out there so that thank you that was my first ever solo session and you have been a wonderful audience thank you so much