 Alright, so again, I know there's lots of great sessions full of bright people at this conference. So again, thank you for joining me. I know there's lots of options, so I'm honored that you're here to hear me speak. I know Drupalcon is a kitten friendly audience, but I had to share my dog who loves climbing mountains. Go a little closer. I had to share my dog who loves climbing mountains. That's my home in Vancouver, British Columbia. As the previous slide already mentioned, I'm Jeff Appleby. You can find me online on Drupal.org as Gapel, or on Twitter as GapelCA or GapelCat. I don't really care whichever. Some of my involvement in the community, I'm the maintainer of the persistent login module. So if you want to have a remember me button on your login forms, it's available for Drupal 8 right now. I also made another module for Drupal 8 for Google Analytics that works a little bit differently than the one you might be familiar with if you've already built pass sites with the Google Analytics module. And if you were eagerly waiting the release of Drupal 8 and checking Drupal release date.com, I hope you found it valuable and informative. It was a fun project for me. I work at a company called MyPlanet. It's based out of Toronto. I'm part of the small and mighty team in Vancouver. And I don't want to forget my talented colleagues in Ukraine. I can try and talk louder into the mic as about all I can change. That one doesn't, the other microphone doesn't work, unfortunately. So object-oriented programming is defined by using objects and the relationships between them and the actions that they can interact with each other to provide code. It's not a big, you know, it's a relationship between the data and the code. It's not a huge change from procedural but allows us to have additional things that we can make use of on top of those base components. And there's a scale between things that are entirely data and entirely codes that are sometimes a lot more like procedural. But the tools allow us to be more flexible in the middle. And Drupal already in Drupal 7 makes use of some classes, some object-oriented code. But it uses a lot more principles of object-oriented code already that hopefully will make things a little bit more familiar to you. And make some of the new things easier to learn. And why do we want to even do it in the first place? Well, some problems are naturally a little bit easier to solve. You know, some concrete concepts if you have a shopping cart and products. Those are easily represented as things that have information and they can do actions. But we can also translate that to some more abstract concepts in our code to make them more natural to solve as well. Some side additional benefits is that we can gain additional structure. We can define specifically how we want things to operate. We have a little bit more than just numbers and strings and arrays. We can actually define combinations of those and we can enforce particular properties of them. It gives us new tools for using items and how the code is related to each other. It makes testing a lot easier in some cases. You know, if you have two functions and one calls the other, you might not always know what that interfunction does. And if its behavior changes, you might not be able to force it to return a certain value. And that makes testing that odor function a lot harder. That doesn't mean objects in themselves inherently are a lot easier to test. But it allows you a structure that you can define the boundaries between different sections of your code and be more confident that they do what you expect. Which makes a lot smaller area where you have to look for problems and potentially make fixes. Performance, there's benefits and detriments. The challenge is, you know, there's more code to write. You got more lines of code. There's also some boilerplate to make things happen. And you might have a lot of classes to accomplish a task. But the other benefit of that is that you can be more granular. You can only use the classes that you need because PHP is an interpreted language. And so it doesn't always need to load all of the code for your entire program if it's not going to use it. And if you're worried about that, PHP 7 has been out for a while and has really big performance increases and is probably going to mitigate any challenges that you might encounter from moving from procedural to object oriented at the same time as you're upgrading. So the basic piece of object oriented programming is you have your definition of how things work. You have the template, which is your class, and then you have an object. Once you provide data to that class and you breathe life into it and you have an object that you can work with. So the basics of defining a class, as you start with the structure, you have the keyword of class that says, here's my component that defines that everything belongs to it. You define what data it is going to contain. So here we have the public keyword. It's a visibility operator, which I'll talk a little bit more about later. You have functionality that can operate within that class and the data that belongs to it. And then the last component of it is the constructor, which translates your initial information about how that's composed into the object itself. In this case, it's just translating it from outside your object into the object itself and storing it. Other components might need to manipulate this data in any manner, and you have the full capabilities of any function. So I just wanted to pause for a moment and point out some of the namespace challenges. You're probably used to snake case where everything is lower case and separated by underscores. With objects in Drupal, there's still some snake case that exists, but the convention is that classes always start with an uppercase character. Each word starts with an uppercase character as well. And then anything within that class, so all of the properties and all of the methods, start with a lower case character, but the same uppercase character on intermediary words. So the other part to this is that when you want to access data within the class, is that you have the special this keyword, which belongs to whichever instance you're operating on. And hopefully through some of the later examples, it'll be a little clearer where that comes in. So in Drupal 7, if you wanted to create an object, you'd have two ways to do it. You could do it directly. You might not use that standard class, you don't always have to, but you would create an array, you'd set a bunch of data, and then you'd just convert it to an object. And the only difference here is whether you access that information within the object with square brackets as an array or with the arrow syntax as an object. It doesn't have any functionality inherent to it, but it is still an object on its own. The other way that you do it is you might have a helper function. So for a node, you only start with the node ID, you enter that, and it returns your fully populated object with all your properties, your fields, everything else that belongs to it. So when you're going to object oriented program, you have the keyword is introduced of new. You specify the class name, and then you give it whatever information you want it to make use of. So date time is a built-in class in PHP. It understands generally any time string, so it can be a time format of a specific time. It understands now or tomorrow. It figures that out, and then it gives you an object. Another way that you can do it is there might be multiple types of information you want to provide to it. For example, for the date time, if you have time in a particular format, you can specify this is the format of my information. Use that to make sure that you populate it correctly. So if you have month and day in a different order, you might specifically know if it's a US or European format. You can tell that to it, and it can use that instead of making that guess and make use of that additional information. And the last one is you might have another object that does some work for you. The date time object shouldn't know about countries or holidays. It doesn't really matter to it, but another object might. It might have its own mapping or its own collection of information or access another API. So you can provide any information, and you can make use of it to instantiate the object for you. So firing up our fake interpreter here. We can create an object. And then of course, if we want to call an operation on it, we can retrieve some information in here instead of just providing just accessing a property directly on it, we're calling a method. So we have the parentheses. We can provide some options to it. So we have a particular format that we want to make use of, and it'll give us a return value. We can manipulate the information inside of the object and say we don't care about the current time so much. We just want to work with the, you know, we want to say what time lunch was. Since that doesn't return any information, we don't get a value back. And then of course, we can do the same operation again to retrieve some information, and we get the changed data within that object. We can have multiple objects, and when we call those methods on each of them, they only change the information related to that particular instance. So encapsulation is where I talk about that public keyword that I said, you know, kind of skipped over quickly. And it's the ability to restrict what portions of your program and what components of your code are able to operate on particular types of information. So in Drupal 7, we kind of hacked it in. If you have a module and it does a bunch of things and you want to have a function that belongs to that module, you can say, please don't use that. This has an underscore in front of it. You know, this is a private function. You shouldn't make use of it. And if you do, it might break, but there's no way to enforce that. So a module might make use of it. You could do an upgrade. If you're not aware of everywhere that actually uses it, how it calls it, what it expects, it could just break on you. So for object visibility, we can make that a little bit more strict. Instead of public, we can say private, and that restricts it so that only this class itself can access that piece of information. So if we go to our interpreter, we can say, hey, let's create a class. And then let's try and get that information from it. And then PHP goes, nope, I'm not going to let you do that. So instead of maybe hoping that someone using your module or your code is going to get back to you and say, hey, I would really like to use this functionality you built. This enforces it so that they have to go, hey, I want to make use of this. And I can't. This needs to change if I need to do it. And you can tell them no. Or you can say, yeah, you should be able to actually use that and change that visibility. But the other component is that we left that method with still public. And it goes, okay. That class is still able to access it because that method is within the object itself. It's able to access that private property. That gives us a couple of benefits. Like I said, that data belongs to that classic self. We know it's not going to change. We know no one else is going to mess with it. So we can make some assumptions. We don't have to worry about it change. We know what it should be. And no one else is going to break that on us. There might be differences between how we want to store the information within the object and what we actually provide to the object when we create it or when we call a method on it. If you're storing a time, it could be a UNIX timestamp. It could be each individual component, the year of the month of the day. You know, if it is a timestamp, is it an integer? Is it in seconds or is it in milliseconds? If you're using that object, you don't have to care what it has inside of it. But outside you know that when you call a function, you're going to get it in a particular format. The other component of it is that we can provide additional restrictions. If we say you can only set this information within the class through a method, then we can say, okay, well, this number must be a positive integer. And if it's not, our code can send an error to the person that's using it to say you did something wrong. The program isn't going to work correctly if you use a negative integer. So you need to correct that while you're programming before some user on your site does something that causes that problem. So there's three different scales of visibility. I started with public. It's the most permissive. Any code that has access to that object can call that method or access that property. It can both read and write those properties. Private is the most restrictive. It's only that class itself can access that information. Anything else will throw an error. And then protected is in the middle. And that allows any descendant classes to make use of that, which leads us into the next thing of inheritance. This is a relationship where one object is a type of something else. And this comes up very naturally within Drupal already, within entities. An entity has certain properties about it. It has a certain functionality that's common to all of the entities across the site. Nodes have some additional special features. They have an author, whereas taxonomy terms don't. Nodes enable comments, taxonomy terms don't. And on the other side, taxonomy terms have some unique features to them as well. So if we're writing it, we can create our classes. Our base class is similar to what we already had before. We just want to create one method on it that's unique to the parent class. And then when we create a child, we have the extends keyword that says, that's the parent. This is what I want to take the functionality from and add my own flavor to it. And within that child class, you can use that keyword to say, hey, I want to access functionality from my parent. Maybe you just want to add something else, do some additional features, some changes to it. It could be some completely new functionality that your child class enables. But again, that this keyword operates on that particular instance. So with that visibility again, in this case, we've said that base method is public. Anyone can use it. If we change that to protected, that child class can still make use of that method. But no one else can. It's literally flashing. Is that one working at all? All right. This is harder than I thought. And then finally, with private, if we change the base method to private, that would actually throw an error because the child class is trying to do something that should not have access to. So the other thing that we can do is we can override methods. If our parent has particular behavior and our child method wants to have that same behavior, but wants to do it a little bit differently, we just define that same method again with the same signature and the same name. And then whenever we make use of our object, it'll use that child's implementation of that method instead of the parent. So the challenge is with this keyword, if you have this within the child, it would refer to the method within the child still. So that's where the parent comes in. It's called as a static method. But that says we want to make use of the code from the parent again and use the parent's over-rideable method. We want to use that value within us, and then you can operate on that in any way that you need to in the child with any further details. Another tool that we have in object-oriented programming is interfaces. Inheritance says that something is a type of something else. Interfaces describe what an object does, but it's less important how it does it. And the other advantage of it is that, well, a child object, like an object, can only be a child of one other type. It can have multiple interfaces. So you can have very granular things that describe the particular functions of what an object does, and completely unrelated classes that implement particular features. So, I mean, one of the easy ones that's built in is can your object be converted to a string? You know, your objects might do varying things and have very different parents, but they all can be converted to a string, and each of your classes can define how that happens. So in Drupal 7, an example of where this happens is hooks. When you implement a hook on your module, you're telling Drupal that your module acts in a particular way. If you call a method with a particular name, it's going to do a particular action. I'm skipping over that slide because I forgot to remove it. So when you're defining an interface, instead of providing the class keyword, you have the interface keyword, and instead of defining a method body and having the squiggly parenthesis, you just say, this is a function. In this case, it's accessible publicly. Well, that usually only makes... It makes the most sense that it's a public method, and you just say that this is the name of it. You can provide any parameters that it requires, and then it ends with a semicolon. And then when you implement that interface, you can actually specify the code that happens. So you define those parentheses and any operations that the actual implementation of it requires. And if you want to implement multiple interfaces, you can. It's just separated with a comma after the implements keyword. And that enables a helpful tool within object-oriented programming called polymorphism. I spent a lot of time trying to find a good example, but it's something that I just have to talk about. And that means that your code can be agnostic about what type of object it gets. So, for example, if you have code that operates on entities, like the field system, it can operate on any entity. It doesn't matter if it's a node or a taxonomy term. The field system just says, I have an entity, I'm going to add fields to it, or I'm going to enable this feature. And it doesn't matter what particular type of entity it is. The other side of it is that it can do specific things for each of those. So for the form API, you have a set of form items. Whether it's a checkbox or a text field, you just have an array of form items. You pass it to the render system, and then it goes, okay, I have a form item. This one in particular is a checkbox. I'm going to hand it to the code to handle the checkbox. And it's a completely different layer that's working with the database. In most cases, you're probably working with MySQL. You can swap that out to Postgres, and your code probably doesn't care in most cases. It's at another layer, your code only cares that you can connect to a database, and the database layer itself handles, okay, this is how I need to talk to MySQL, or this is how I need to talk to Postgres. So one more thing before we can actually put our code somewhere is namespaces. How do we organize things? In Drupal 7, it was prefixes on your functions and your, you know, if you had global properties, if you had global variables. That helps separate out what code belongs to what module, but it has limits. I don't know if any of you have ever run into unintentionally implementing a hook for another module. If you have an underscore in your module name, it isn't well defined where your module name ends and the rest of the function name starts. So PHP in 5.3 added native namespaces. So the keyword is namespace, it starts at the top of the file, and the convention is that it's the project name or the organization name and then the project name. So for a module, it's part of the Drupal organization and it's, your module name is the project. You'll see this as well in symphony. Everything starts with symphony and then it'll have whichever symphony component it is. If you want to use stuff from another namespace, the problem is that all your code within your class assumes that if you're looking for another class, it's within the same namespace. So you would have to write out the full name to get to it. Obviously that gets a little tedious if you're using a class a lot of times. You're going to have to repeat it a lot. So it gives you a shortcut. The use keyword says, I'm going to use this class in my code. If I ever reference that particular class without any namespace, that's the one I want to use. If you have a conflict, you have two classes that are named to the same because you can do that now with namespaces. You can actually give it a separate name. You can say, I want to have it used as another name only within this file, which will save you a lot of typing. And then the other problem that it introduces is how do you use a global class? So the datetime is built into PHP. If you tried to use just datetime in your namespace, it would try to look for Drupal, my module, datetime. And it's going to cause a problem. So in this case, it says you just use the single backslash to say, I want a object or a class that's defined in the root namespace instead of one that's in whichever namespace I'm in. If you don't like the look of that slash, you can also use the keyword, or the use keyword in this place as well at the top of your file. So with those namespaces and that consistency, it makes it a lot easier to find where we should write our code and where our code should be. This was pretty messy in Drupal 7. You had a bunch of different ways. Your module file could get pretty big, so you'd have a utility. You'd throw it in another file, but you'd still want to load it on every page load every time you load your module. If you have a page callback, you might have some code that's only relevant to that page callback. Drupal makes it so that it doesn't need to load every time, but it has a different method for loading that code. And then another one is that you're using some code from another module. It provides an API. It doesn't want to load that code every time that a page loads. Then you have the module load include. To say, I have this code, I want to make use of it. I need it within this function, and then after that is run, then you have access to all the functions that it provides. So with namespaces, we have some consistency. Drupal knows that where modules are stored for my module in the modules folder. And then the only thing that it requires is that your classes are in the SRC directory. And then it can map your namespace to directories and your class name to the file name. Same capitalization throughout. And then Core does the same thing. In this case, your Core modules are in a different folder, but it still knows where to find the node module. It looks for the SRC directory. And then it maps. The entity namespace goes to a directory. The node class name goes to a file name. Beyond that, when you're making use of other libraries like symphony or guzzle, if you're doing HTTP requests, it knows that those are stored in the vendors directory of your system. And then they have a little bit of a different directory mapping, where it is. It knows where within that library its classes are stored. And it finds each file. So in Drupal 8, we want to make use of services. And this is a particular way of building objects that are focused on doing things as opposed to being things. Is that they have a bunch of operations. If they have property use that belong to themselves, usually they're just references to other services, things that it needs to make use of. And they're all instantiated objects. They're all instances of a particular class. But you only want, typically one of them. You only have one current user that you're making use of. So Drupal provides a container to organize them. So if you're working with your procedural code, you have the global Drupal class. And it has a static method called service to access any of them. In many cases, there's a more specific tool to access the session. But that service is available so you can make use of it. And then for a lot of common ones, you have shortcut methods. So in case you want to get configuration, the configuration factory service is available as config. So if you want to get the site information from the config, you can pull that out directly. Similar with the database, there's a function directly on that so that you can do queries a little bit easier or the current user and providing their information. But because we have those organized, all of those services that we want to make use of organized, we can make use of dependency injection, which sounded scary to me and confusing, but it's pretty simple. In most functional code in Drupal 7, if you want to access the database, you call a method. In here, we want the database directly so we get connection. In other instances, you might use the dbSelect function to pull out a select object. But in some way, you're getting that from the global state and then you make use of it. Dependency injection just changes that so that your function requires the database service. So your function doesn't need to know how to retrieve the database. It's given it and it just makes use of it. Now that's a hassle. If you had to deal with that with every function, every time you wanted to do something and as well within Drupal 7, it wouldn't always know where you needed that database passed in. So when you're building services and objects that actually make that a little easier, they're injected in the constructor. So when you create your own service object, it has the constructor that says I need a database. I store it within the object itself and then any method on that object from that instance forward can make use of it from within the object. So the last component that I have to work through of a lot of these principles. So if you want to build a page controller, in Drupal 7 you would have a function that would return either a render array or a string. In Drupal 8 you start with a base class that gives you a bunch of functionality. It's an abstract class because you don't create instances of it directly. You extend it for your particular use case by creating a child class and it automatically implements the container injection interface for you. And the only thing that the container injection interface defines is that your class must have a method called create and it's a static method so that when Drupal needs to create a new instance of your class it knows that that method is available and it's going to pass it that service container from Drupal itself where everything that you need from your database to your current user to your configuration is made available. And in this case the base class doesn't need any options to create a new instance it just does a new instance that static keyword is just I want to create whatever class I'm defined in so in this case it's the controller base and then it returns it. So then when we want to implement it we create our base class we define our namespace saying that it's part of our module it's within our controllers in our module we give it a name we say that it extends that controller base I am missing one thing because the slide doesn't have a whole lot of space is the use statement to say I want to make use of the controller base class from Drupal core and then here we have we start out with our constructor that says we need a database and we're going to store it this doesn't matter where it doesn't keep track of where it gets it from but it stores it in a private property belonging to that class itself so that no one else can mess with it can change it and then we're overriding that create method from the parent it still receives that same container but in this instance instead of just creating a static instance creating a new instance of the class we say that it needs the you know we want to call the container we want to return the database service from it and use that when we create our object so now that static method is a little bit more important we couldn't say that we want to create a new instance of the controller base and we shouldn't say that we want to create a new instance of my controller what the static does is says wherever this is defined whatever type of object whatever class we're trying to create create an instance of that class so in this case the static resolves to my controller if you had a more complicated dependency if you had something else that extended from the my controller itself it would automatically create an instance of that item other sessions maybe you've already attended them they've already all happened at this point but these are three other sessions from the conference that build on some of these things dependency injection is a little bit more directly goes off of you know teaches more about that service container and creating your own services another one other ones for building Drupal 8 modules where Drupal 8 kickstart and altering extending and enhancing Drupal 8 some of the videos probably already up I don't know if all of them are yet and as well a helpful tool some of this boilerplate some of this code is difficult and you might not always remember the keywords Drupal console has some great tools to help create some of those so you can say I just want to create a new module I want to create a new page controller or a new form for my module and it'll automatically write out a lot of those of those of the code you need to get started with those I know it's a little bit difficult it's another thing to learn some of those keywords but that is a very helpful tool to start working from those examples finally I'm just standing I'm going to be at the sprints tomorrow or not tomorrow Friday I hope you'll join us it's a great opportunity to get familiar with some of the new pieces of Drupal 8 building some of your own solutions understanding how it works and supporting other people and getting started and please let me know what you thought of my session as well as all the other speakers really appreciate feedback and would love to hear what you think that's the last slide in my deck I'm happy to answer questions and I do have a code editor that hopefully I can type out and explain things if you have any Suzanne so I think I'm finally beginning to understand object oriented my question is is there a resource that you know of not to learn object oriented but to begin learning how to think to program object oriented does that make sense if I start a project I understand what I want to do to create it procedurally but now as I start thinking about object oriented when do I need to decide I should probably start building a class out to do all these things rather than a function does that make sense I think the big challenge is I know I did it when I started programming with object oriented is the kind of the initial desire that you get is to create everything I want to organize a function function so we'll create them as static methods within a class and within Drupal it makes it really easy I didn't have the ability to go into a bunch of the YAML and defining services but there's other great resources for that and I'm sure some of the other sessions gave those components but that's somewhere where you start like if it's a bunch of rate related functionality that's a great instance to start the service class it's and then when you're manipulating data if you have a bunch of information that's joined together if you would create you know if you have an array of a bunch of related information that's probably a good instance to say okay well I should organize this into a class especially when you know you have defined keys within your array that have specific meanings to do specific operations with them giving it that structure as opposed to just having those arbitrary array names is a great place to start you might never need inheritance or interfaces on those classes but they give you a structure to start working with I don't know any other like learning resources off the top of my head but I'm sure there's some great ways to start learning about organizing some of your objects and data when you do need to start getting into inheritance so the question was is there a good Drupal module to compare a before and after of what it looks like in Drupal 7 what it looks like in Drupal 8 some of the core classes might be a little bit difficult I mean note obviously as a pretty big module once you dive down into it I'm trying to think off the top of my head yeah yeah there is an example project and I don't know if they have examples like direct examples of here it is between the two versions but they have a lot of example implementations and so some of them especially for page controllers compared to page callbacks or form classes versus form callbacks those would probably be one that it might not be like here's a direct comparison between the two but those would be a great thing to compare to each other to work see what the difference are and some of the additional things that you need to work with yeah so Drupal 8 or Drupal LA should have a session comparing flag module I know I saw another session at a PHP conference where someone went through converting the contact module in core and it has a lot of other pieces that change between the two so that's one where I think it's probably a little bit more difficult because contact forms in Drupal 8 are actually entity types which is a big expansion over Drupal 7 but there are some comparisons and if you're doing more porting modules that might be one to explore some of the new features that are available in Drupal 8 yes yeah native PHP namespaces were available in 5.3 Drupal 7 initially required 5.2 so they couldn't make use of it but again I think the latest supported version of PHP is 5.5 right now so if you're using a version of PHP that doesn't support namespaces you should probably be upgrading yeah I believe the Drupal 8 requirement is 5.5 it uses another feature called traits that I didn't get into you might not have to interact with it until you get more involved in understanding those another session somebody recommended the Google Analytics module for 8 yeah I'll just repeat that Google Analytics my own module is a bit of a competitor to it I think it is a little bit of a simpler example of seeing how to implement it and it does actually use objects so I don't think I have it pulled up what's it the project name is PHP this is hard because I'm not mirroring my screen see if I type that right and that I have Wi-Fi access but yeah it uses objects to represent the different commands that you have available in Google Analytics so there's a basic send command and the when it sends your actual like tracker information versus if you're sending an event which you usually wouldn't do from PHP but it has a very simple class hierarchy to make use of those commands and then as well it does have implementations of an in-interface it uses events which are a little bit more complicated generally a lot of the stuff in Drupal 8 you can still make use of hooks for altering forms and pages and that sort of thing but you might have to use events and the GACSP module does have an instance of using events as well as some helpers to make procedural code a little bit easier no Wi-Fi for me this module is one I built it's for Google Analytics integration it's not quite feature parity to the Google Analytics module that most people use but it does have examples of symbol classes class hierarchy just for storing different properties between Google Analytics commands that are available overriding operations between the few of them I don't want to over-hype my own work in this session but it does have some good examples if you're interested in exploring