 Thank you very much. I'm just going to check. Is that good? Can everyone hear me okay? Good. I'm Jack Panux, and I'm going to be talking today about object-oriented programming, design patterns, and test driven development, as you can probably tell from my slides. I have a habit of speaking quite quickly sometimes, so I'm going to really, really focus on trying to not do that, clearly and slowly. If I'm not doing that, and I'm speaking really fast, you can feel free to interrupt me and tell me to slow down. I'm going to really focus. The slides for this talk, I've got lots of links and stuff and code samples, so if you want to see those slides, you can go to this address at github.com. The slides have been put together in Markdown, so the Markdown file is there. I haven't made a PDF yet, but I will do, and I'll put that on the speaker deck or something afterwards. I'm going to introduce the actual concept of this talk. You may be wondering what object-oriented programming is. Object-oriented programming is something that I struggled with for quite a long time. I first started learning PHP, I think in 2002 or 2003, and at that point it wasn't really part of PHP, so you could learn PHP without having to learn it. A friend of mine who was a .NET developer, he was trying to explain to me why object-oriented programming was better, and this was back in 2002, he drew diagrams and everything, and I didn't understand it. I spent over 10 years not understanding it, and it's kind of one of those things that it's only since I've been working on the VIP team at Automatic for the last year that I've really come to understand all of the concepts, I think, anyway, of design patterns, OOP, and test-driven development, and that's why I thought it would be good to try and package them up in a nice little talk. In a sense, these are quite big topics, so trying to do all three of them at once could be arguably described as stupid, but I think it's going to work, and I'm kind of giving in with some quite simple examples of all of the different aspects of these three topics. So what is object-oriented programming? This is the definition on Wikipedia. I won't read it that, actually I will read it that. So Wikipedia describes that object-oriented programming, OOP, is a programming paradigm based on the concept of objects, which may contain data in the form of fields, often known as attributes, and code in the form of procedures, often known as methods. Now, if you're a programmer, that might sound kind of logical, if you aren't, that might sound like complete jargon, and I think the main thing to try and take away from this definition is just this thing about objects, and it's kind of obvious with it being called object-oriented programming, but the idea is that our code is going to be packaged up in objects, unlike maybe normal other types of programming where we might have just loads of code just generally doing all sorts of different things. Object-oriented programming kind of started to become a thing, it has its roots in sort of the 1940s, 1950s, this is Grace Hopper, this is programming in the 50s, and it kind of has gradually developed throughout the last century, but it didn't really become a big thing until the 90s, and there's this book by a guy called Ida Jacobson. He worked on a project I think called Objectonomy for about 20 years, and he was sort of doing all sorts of experiments with object-oriented concepts, and he wrote this book, which is arguably the kind of seminal work on object-oriented programming, and when it became really big with a whole load of languages which supported it fully. In the 80s there were some languages that kind of worked with it, but it kind of really got serious in the 90s. These are some of the languages that support object-oriented programming, and these are kind of where it's come from. So you can kind of understand in the 90s graphical user interfaces became a big deal, and Apple's support of object-oriented programming through Objective C, that's the language that they wrote, the COCO framework, which is what OS X, and now Mac OS is written in, it's kind of changed over the years. And then you have these languages towards the bottom, which are the web languages, .NET and Ruby. Java was kind of the big language which set this whole thing in motion, so anyone here who's done some Java programming will probably be very familiar with everything I'm going to talk about and can leave. But yeah, Java was where this got really big, and then it's kind of, it's migrated its way to the web. It was kind of slow coming to PHP, which I think is partly why it's in a kind of funny place with PHP, and why a lot of PHP projects are necessarily entirely object-oriented, or are a mixture of different things. It was kind of fully supported, arguably, in PHP 5. Pryda that there was some support for object-oriented programming, but a lot of the books that you would have bought that would have taught you how to do basic things with PHP wouldn't have mentioned object-oriented stuff at all prior to 2006, and that was why I kind of struggled to learn it myself, because I'd already learned the other paradigm. Now as some of you might already be doing the maths, WordPress was established in 2003, three years before PHP 5 came out. So WordPress is kind of a weird mishmash of lots of different types of programming. Over the years it's kind of, it's leaned much more towards the object-oriented side of things, but there's still quite a lot of core out there which is not object-oriented, and lots of programs aren't object-oriented. So again, it can be quite difficult to work out where this all fits in. So before I get into the code examples and try to explain it, I'm going to kind of try to explain what is not per se object-oriented programming. So PHP started out as quite a basic language. It was for doing kind of basic templating things and having bits of variable content on a page. So let's take a look at something like processing a form. Oh sorry, before I do that, yeah. So normal PHP, I still think of this as like normal PHP as in not object-oriented. This tends to come under the banner of procedural programming. So procedural programming, it's kind of a very broad term and it's object-oriented programming. I can have procedural programming in it as well. But procedural programming is broadly just kind of writing code in the way that your imagining machine is going to interpret it. So you're writing it in the same order as what the website or plug-in or whatever is going to do with it. So it can be described, I describe it as a linear. I say it's written in the order that it's executed, and it's not necessarily modular because it can just be one massive long file. There's no reason to break it up because you're just going to write all the code that you want to do, all the things you want to do. So here's kind of a really basic form handling thing. In typical style, when I was trying to just mark something up, it's like the stupidest bit of code I've ever written. But it kind of hopefully gets my points across. So you can see that what we're saying is like if a post name has been set, if something's been submitted via reform, I haven't got the form on here, we're going to just do some really basic things. We're going to sanitise the text field first to make sure that there's nothing nasty in there and we're not trying to have some sort of injection attack. And then we're going to say if the string length is less than six, then we're not going to be happy with that and we're going to give a message back. This is kind of really simplified so you wouldn't ever want to do this in production probably. But this is kind of some really simple procedural code. And it could exist in an object, like a really basic .php file might work. And then beneath this, you might have like the HTML stuff and you might have your form and your inputs and everything. And that would be like a simple bit of PHP in a PHP file. Object-oriented programming is non-linear in the sense that you're thinking about things in a much more kind of architectural way. You're not just thinking about like, how do I solve this immediate problem? And as a result, what you end up with is a series of self-contained objects that can work together. And it's modular by design because you're breaking things up into different objects. And if you're still worried about what an object is, don't worry, we're coming that safe. The benefits, and at the end of the talk, I'm going to talk about some of the debate around this and there are some people that don't like object-oriented programming and that's totally fine. But the benefits that were certainly within the WordPress ecosystem are that you've got to reduce the possibility of naming clashes. So some of you might have seen if you looked at some plug-in code, if you want to define a function, it exists things, so you can say like, if this function exists, then don't do this. And there's obviously, although there are ways of trying to make sure that your functions don't clash with other functions, there's obviously always a chance, especially with the ever-growing thing of WordPress, that even if you have the name of your plug-in at the start, so it's like my awesome plug-in underscore filter, something or other, there's always a chance that another plug-in is going to come across with the exact same name and they could become incompatible because they just have matching function names. This can theoretically also happen with objects, but the nice thing about object-oriented programming is that you're grouping things together under an object. So your chances of clashing are much smaller because you only have a few high-level objects which might have the same names, but you don't have loads and loads of other functions that all might clash and you don't have to keep saying like if function exists, that kind of thing. The other benefits are modularity, and as I say, it's possible to be modular with other types of programming, but it's kind of by design with object-oriented programming. And reusability, and again, you can make reusable code that's not object-oriented, but it's kind of more obvious how it works when you're starting out with something that's object-oriented. So, why and when to program in an object-oriented manner? This is kind of the classic thing that people try to do when they explain object-oriented programming, and some people deride it because they find it annoying. You sort of talk about a real-world object, and I actually find this quite a good way of explaining it, so I'm going to try to explain it this way. I've read a lot of the books that talk about this paradigm, but let's say we have a yellow car, and we want to describe it as being an object. So, in a programming way, this is how we might define it. So, our car is going to have some attributes, and these are attributes in the way that you would understand attributes normally, or in video games where people have attributes and that kind of thing. So, the colour of the car is yellow, it has two doors, and it has a luggage rack. And then we're going to have some methods. Now, methods are things that the object can do. So, in the case of our car, we might say that it can accelerate, and it can break, and it can steer, and these are different ways that we can describe what our object can do. I'm going to keep using my car example, but I'm just going to show another example before we come back to this, just to kind of relate this more closely to WordPress. So, in the same way, you could describe a blog post using some similar things. So, we could say that a blog post has these attributes, it could have more attributes, but let's say it has a title. Let's say it also might have a date from when it was published, and it might be sticky, or it might not be sticky, so it might be at the top of your post or not. It might have some other attributes, it might have an author, it would definitely have other attributes. But this is like three sample things we can use. And then again, there's the methods. So, it can be updated, it can be published, it can be deleted, for example. But I'm going to keep using the car because I like it. So, how do we now program our car in an object-oriented way? Well, we have these kind of new bits of language. If you're used to using PHP without objects and without this whole thing, then there's going to be a whole load of language I'm going to show you now, which will look completely unfamiliar. And as someone who started learning PHP it was really a big thing. I struggle with this because it just seemed like all these people just knew these extra things you could do in PHP that I'd never heard of. It just seemed to come from nowhere. It was like, how do you know that you can write that and that does stuff. But I've come to gradually understand where these things came from. So, hopefully I can get that across. We have classes, so you're going to see a lot of classes. We have attributes also known as properties. People have different ways of describing it in different languages. In most of PHP, it's actually properties, but I've used the word attributes because I'm difficult. Then we have methods, which I'm going to show you as well. And then we have these extra keywords that do extra little things relating to how an object works. So the key ones are private, protected and public. I'm going to explain what they do as we move along. But that's what you really need to know at this stage. So, in PHP, this is how you define a class. It's quite simple. You can literally write class, and then the name of the class. There's a convention of capitalising the starting letter. Whereas you might be used to with your PHP variables not having a capital letter at the start, you have a capital letter at the start with a class. Now, I haven't explained what a class is. Some of you might be thinking, what's a class? The term I've seen quite a lot around a lot of different tutorials and books is that a class is a blueprint for the objects that you want to produce. So, obviously, this whole talk is about objects, but we're going to be looking at classes quite a lot because the class is the manufacturer. I kind of like the idea, as well, of thinking about a class as a factory, because a blueprint is quite good, but the class also kind of builds things. So it's almost like a factory for your objects. It produces objects. But you define in the class how that's actually going to work. So if we start building out our car, we're going to describe the attributes of the car. Now, to begin with, we're not going to say anything about what these attributes are. We're just going to say that the car can have these attributes. So we're going to have color, we're going to have doors, and we're going to have lucky track, which is from my original example. And then we've got our methods, which I talked about. This is what the car can do. So we can accelerate, we can break, and we can steer. So you can see accelerate and break. They're just going to echo these stupid things. And then the steer is going to be taking an argument, and that argument is going to be the degree. So you can imagine in a really simple environment if we had a steering wheel, and as it steered, it sends a message to the object and says, right, this has happened. It might bring within the degree that the steering wheel has turned. So it's turned 15 degrees, and then we can use the argument to say that's going to be 15 degrees to the right. If it's minus 15 degrees, we can say this to the left, and then we can make our code react to it. So in a very basic way, this is our car factory. You can see I've now added some, like, defaults to our attributes. So we're going to say the colour is going to be white, the doors are two, and there is no lucky track because it's false. And here we have, like, our basic class. So how do we then use this in PHP? So at the moment we've obviously got this, but if you just write this in a file, it's not actually going to do anything. So this is how we build a car. So you're probably quite used to seeing how a variable looks. It's just a dollar, like, a new car. What you call the variable doesn't matter, that's totally unrelated, but we're just going to say equals new, then we've got that capital C, because that's how my class works, and then car, open bracket, close bracket, we're not going to put any arguments or anything at this stage, but that creates a car. We can then do things with this object that we've created. We're going to maybe change the colour to yellow, we can change the doors to four. You may have noticed something I didn't explain in the few slides back, is that we have this public thing up here. See my pointer. Now, this is one of the keywords I talked about. All this basically means, with your attributes or your properties, is that if it's public, anyone can change it and anyone can see it. That's all that really comes down to. So I'll explain what the other two mean as we move on. You've probably probably started to guess, but it's a little bit more complicated than the other ones. You can also decide if your methods are public or whatever. By default, your methods will be public. So the fact I haven't said what they are, that I could put public function accelerate, public function break, that's how that would work. But could we do better? In my example, this is kind of a bit, doesn't that break? If we're going to have lots of attributes, we have to go through and describe what they all are after we've created it, and we're creating it. There's a method called construct. It's underscore, underscore construct. And this is how it works. So the methods I'm designing for now, so it will fix on the screen. It's a protected method that any class can have. And this basically just tells the class what's going to happen when an object is first created. So there's all sorts of different things we could do here. In our example, we're going to add some arguments into our constructor. So we're going to take colour, we're going to take doors, we're going to take a luggage wrap, and then we're going to redefine the attributes of our object. Now you might also be noticing that the whole dollar, this, and then the arrow and everything, and what's that about? Well, the main difference between attributes or properties and normal PHP variables is that in the context of a class, you have to actually explicitly say what you're changing relating to that class. We couldn't just use colour because it kind of relates to something called scope, which colour is going to think about a variable called colour. It's not going to think of the attribute of this class. So the way we deal with this is we say dollar, this, colour. And obviously we are also passing in these other arguments with variable names that are going to be matching. Again, you don't have to do that, that can just be whatever you like. But that's how I've done this one here. So let's say we want to build a purple car with four doors and a luggage rack. Well now we can do it like this. So we can now pass our constructor arguments through our instantiation of the object. So we say it equals new car as before. And then we're going to say purple, which was the colour. We're going to say four, which is the number of doors. And we're going to say the luggage rack is true. And now we get a new car, which is purple. And I've assigned this to a variable called purple car. So, something that's very important in object-oriented programming and especially I read a lot of code now on the VIP team at webpress.com and that's documentation. So we've kind of got our basic class setup and at this point I really think it's important to hammer home documentation. Because when you're trying to read someone else's code or even when you're trying to read your own code that's the scariest part of this. You can often lose track of what you were trying to do in the first place and it kind of gets a bit annoying. And it's really annoying when you're trying to read someone else's or when you're working as a team. It's not the best way to work if you're not documenting. But it's kind of especially important I think with object-oriented programming because it's not written necessarily in the order that the machine is going to read it. So going back to what I was saying at the start it's often more obvious with procedural code exactly what's happening. And this is one thing that scared me about OOP for such a long time is that I like the fact that I could just see what was happening with my procedural code. Whereas when I looked at object-oriented stuff it was like oh it's referencing this object and then you have to kind of start moving around into this sort of work or PHP documenter. What this does is if you've documented your code like in the actual code itself PHP documenter can pull out the documentation you've written into a more like readable format so you can create a Wikipedia of your site and it has all the documentation taken from the code itself. You don't have to maintain it separately you don't have to have a whole separate file and if you change something in the code you just change the documentation to match and it just all gets automatically done. about PHP Documents for itself but as you might imagine it has a certain format that it needs to understand how you've documented stuff and it's quite straight forward. So this is how we document a class. Now PHP Documenter will expect a short description to begin. So the short description is supposed to end in a full stop and that's what we have at the very top where we say defines car factory full stop or period for American. And then we can have a longer description which can go for as long as we like after it. My description here isn't very long but we just say the car class produces cars. And then we have a couple of extra flags that we can put in there so we can say what the package is. You don't have to do this. These are optional. It's worth putting the package in. So this would be if this was a plug-in, this would be the overall slug of your plug-in. You can put the author for what it's worth. This class is completely useless but I made it. And then you have who the copyright is. And you can also at this point, and you probably should do this, you can declare a license. And if you're working with WordPress, that license should be the GNU version 2 license. But yeah, so that's how we can document a class. Then we can document our properties and this might start to look quite verbose. You're just thinking, ah, this is actually quite busy. But actually it's really nice because this can just be as human readable as you like and you can explain things as much as you need to. So it follows exactly the same layout as before. We have the short description to begin with, then we have the longer description, and then we explain what type the attribute is supposed to be. So if you're not familiar with types, I'm hoping some of you will be familiar with types, this is just like a way of grouping together different types of variables. It's exactly what it sounds like. The most basic type is probably a string, which you've all seen. That's something in quotation marks. That's normally going to be a string. In PHP you can also just have a straight up number or an integer. I've actually put var integer. I think it's actually var int is what I should put there. So this is just a straight number. So a number that's not in quotation marks, that's going to be an actual integer as far as PHP is concerned. And then we also have booleans, which you're probably familiar with. That's true, false, that kind of thing. Theoretically also ones and zeros, but true and false is the more common way of doing it. And yeah, so you can see I've explained what each attribute is and I've explained what type it is. And finally we have methods. Again, this is a very similar pattern. So we have the short description to begin with, ending in a full stop, the long description. And then we say what the method is going to return. Now the method might not return anything. This is again optional. You don't have to say what it returns. But if it does return something, then you write that in. You might have noticed earlier on I said I was saying echo tie asquil, which is not very, it's kind of a bit imperative. So we don't really want that because it's going to like to potentially do things that we don't want our code to do. So this way we're just going to return tie asquil and then we can decide in our subsequent code what we actually do with that. We can echo it if we want to. We don't have to echo it. But yeah, and then the documentation explains what's happening. So unit testing and test driven development. I hope you're all kind of following along with me vaguely. The thing about unit testing, I've watched quite a few talks about unit testing and this was another topic I found quite difficult. When I first started working automatic, I hadn't really heard of it and someone who was really into it was just saying it's ridiculous how like so much of the code we have automatic isn't tested. And I was like, hmm, yeah. And then yeah, the more I could have, I was thinking surely we do test it but then I started to look into what he actually meant and now I understand it better. The thing about testing is that when you see talks about it on its own it's quite an advanced topic because just the concepts of why you would want it can initially seem quite intimidating. And I also think although you can theoretically have unit testing in non-object oriented code, it makes the most sense in object oriented code and it wasn't till for me kind of all these things came together that it all really started to make sense. So I want to just talk really briefly about testing and about why you would do it and how it works and just a really simple example. Again, there's another piece of software here called PHP Unit. It's quite easy to download it and run it if you just Google PHP Unit. I think it's phpunit.de, it's German, and you'll see some explanation. I've got some links as well at the end to kind of take you back to this. But let's have a look at a basic test. Now, this might look a bit overwhelming. It's kind of quite a lot of things all happening at once. Ashley, before I'm going to hide this again. So let's just think about the code I was writing and think about why we might want to test it and what the testing might entail. As I was saying, with procedural PHP, you're writing it in a way that the machine is going to read it. So although testing is possible, it's quite easy to test procedural code yourself because you can just be like, well, if I submit the form, do these things happen that I'm expecting them to happen? You do still have, oh, five minutes, right. I'm going to hurry up. So you are still going to be wondering if every aspect of the code works, but it makes more sense to just kind of sit there and test it yourself. The minute you start writing object-oriented code, your methods and the different things your code is going to do, they're kind of isolated on their own. So you might start writing like our car class before you're actually going to build the other thing that then runs through and actually builds these cars. So you're going to be thinking, well, does the accelerator thing work? Does the brake thing work? And to test that, you've got to write up a bit of code. It's kind of annoying to just test it on its own. So let's say we want to just like see if our whole class is working in the way that we expect it to. That's where testing comes in. So you can ignore the little bit at the top. This is what's called a namespace. All it's basically saying is that we want to use this thing from PHP unit called test case, and we don't want to have to write out the full path to it every single time. So it means that down below where I say car test extends test case, I don't have to write PHP unit because we can just go straight with that. We're also going to require this class car.php. This is all available in the GitHub repo. I've got a link at the end as well. Now, there's a couple of new things being introduced here, and one of them is inheritance. And that's exactly what it sounds like. You can write a class that extends another class. And all it really does is it sets whatever the other class does, they become the defaults for your new class. So you can inherit what that class does yourself. So, yeah. There's some basic things that we get from PHP unit. We can set up our test and we can tear it down. So these are just things we want to do that are going to help us test something to happen. So in set up, what's the thing we're actually going to try and see if it works. And in tear down, if we want to clean up, we can do that too. You can also see we've got an attribute at the top or a property. It's private, it doesn't necessarily matter, private compared to public what I said earlier. Private means that only the class that you're writing can change that attribute. Not anyone else can change it. So that code I had at the start would just change the colour of the car to yellow. That would throw an error because it's like you can't, you don't have the right to do that. It's private. All the real action happens in the very last bit. This is where we create our actual test. And again, the convention in PHP unit is to use the word test at the start of your method. We have what are known as assertions. And this is the basic thing where we just say we want to check that this is this. So you can see in our set up we're creating a new car, it's yellow, it's got four doors, and it has a luggage rack. And then all we're doing below that is saying is this what's actually happened because we say our constructor method might be broken or someone's changed it. This allows us to see if it definitely works or not. So we use two of the basic assertions that PHP unit gives us. Assert equals and assert true. Assert equals. You pass it the first argument and the second argument and it just checks if they're the same. So you can see this car color is it yellow and if it's not yellow it will fail. And then we say this car doors is a number, it's an integer, it's four. And then we say is the luggage rack it should be assert true. We don't have to actually write in true because it's just there, it's already done for us. And if all of that has worked, this is what happens. So in our command line, once we've installed PHP unit, we can just run it on our test file. So my test file is just called test.php. I don't have to put the .php because PHP unit will just guess that. You can also have lots of different tests in a directory and you can just run them all at once. So you can see what happens is it runs the test. At the bottom it says okay, one test, three assertions and we know it's passed. If any of those things haven't worked it failed and it will tell us why it's failed and where it's failed. And then we can just have this automatically running when we're writing our code. So you can imagine on a sort of a grander scale we'll know if we've accidentally broken stuff before we actually push any of the code. There are other ideas around testing that we should actually write the test beforehand because that can then help you like you're sort of writing the code to match the actual thing you want it to do rather than just tapping away randomly and trying things out. So I'm not going to go into too much detail on that and I'm just running out of time so I'm going to just push on and get the last bit done. Design patterns, I'm not going to talk about in a great deal of detail but there's a couple of things that relate to WordPress that I think are worth just thinking about. There's kind of the two most sort of core concepts to how design patterns work and one of the biggest design patterns which is a singleton. So singletons are used quite a lot in WordPress. A singleton is an object that's only intended to be created once by a class. So you saw we were making like cars or blog posts and that kind of thing and in the case of a singleton we only want it once. So there's quite a lot of these are used within WordPress and I'm going to talk about one of those in a minute. And then inheritance which you already saw so the way I was doing it with the test case we extend something that already exists and we can do something else with it. So inheritance in and of itself is not a design pattern as such but it's core to lots of different design patterns and design patterns sorry I'm trying to brush along so I can actually finish design patterns are lots of different pre-written ways of dealing with problems that we all face. So in PHP there's design patterns around how to deal with databases how to deal with a lot of the like how to deal with form input submission that kind of thing. There's all these different patterns and there's a whole load of them that already exist in WordPress and you don't need to worry about them too much if you're just kind of getting started but as you move on it becomes a bigger thing. So object-oriented programming and WordPress in practice probably one of the best examples of something where you have to sort of understand a bit of what I've just showed you is the widgets API. If you want to create your own widget you extend a core widget class and I'm going to show you how that looks and then yeah you can then use a hook to add your widget back in to the system but it uses fundamentally a class extension. We then have the walker class if you want to create a custom nav menu that does something wacky you can use the walker class you can use it for creating lists of pages and that kind of thing and again you extend the walker class say what you're going to do in your walker class pass it back to WordPress and a very good example of a singleton is a WP rewrites this is the kind of central object that manages rewrites so if you just choose like a post name as your URL slug WP rewrites is going to work out what post name that actually is and what post it should show you because obviously it's going to need to use post ID or something so it does a whole lot of different things so this is how the widget API works some of you might have already seen this before this is kind of quite simplified so this is just a basic example in the WordPress codex so we're going to say like myWidget extends WP widget and then we have a series of things like the constructor which we can take from the codex we can say like how we're going to what name our widget is going to have and the description of it and then you can see like this stuff is kind of just already like you can just copy this and you just fill it in with the bits that you want as it continues there are a couple of methods that we're going to want to use the main one is widget we're going to say what actually happens on the front end with our widget a second one is form this is the form that's going to appear on the admin for anyone who wants to interact with our widget and change what it says that kind of thing you've probably seen this with widgets in WP admin and the final one is update that's the final method and in that method we're going to say how we actually record any changes someone has put into that form so we can say like if we're going to update options that's how we're going to deal with it it takes obviously two arguments it takes the new options and also the old options you can use that to just check if things have changed see what's happened the walker class I won't try and explain but there's a very good touch plus article so again these links are available but I recommend reading that the walker class is a little bit more complicated than creating a widget but yeah it's a similar idea you extend the walker class to your own ideas and then you pass it back in so in conclusion I recommend checking out the WordPress plugin boilerplate if you want to get into plugin development and this talk has kind of inspired you in any way if you may well not have done the boilerplate is a really good place to start it's an object-oriented plugin which does nothing and you just kind of fill in all the different gaps it was written by a guy called Tom McFarlane who I really liked his stuff he wrote a really great series for touch plus as well about object-oriented programming in WordPress I'd highly recommend it because he actually kind of explains the boilerplate basically because his series is about how to build an object-oriented plugin if you just look at the boilerplate without any real advanced knowledge it can be quite intimidating whereas his little article will explain how the boilerplate basically works and how that's come to be he started off the boilerplate and he created it in the first place now we're not to program object-oriented so there's kind of a thing where people learn it and then they're like everything's going to be objects now it's all great and they sort of forget about the concepts of procedural programming if you're like processing a form that kind of thing procedural is still absolutely fine if you're making something really small my time is completely up so yeah you don't always have to write things object-oriented and there's some good jokes about this like the problem with object-oriented programming precedence to just one thing like trouser-oriented clothing, down-oriented language these things you wear trousers and you wear shirts and other things you shouldn't just focus on one thing final link functional programming which is a whole different thing and it's really worth looking into if you want the complete opposite view and if you hate the idea of object-oriented programming and everything I've just talked about go read this article it's actually a guy, a Singapore blog and it's great, it's 10 years old now it's a kingdom of nouns it's like a story about a world where only everything is only object-oriented it's very anti-java, it's quite funny so OOP is not necessarily the right way but it's much better than this and this is my face when I look at a big spaghetti code that's been submitted to WordPress.com it makes me very sad so at least it gives you some structure and some order to what you're trying to write thank you sorry I guess there's no time for questions that was quite a simple explanation of a lot of complicated stuff if you guys have any questions for him we are open to questions to Jack anyone I'm also around I'm at Jack Lenox on Twitter and stuff if you want to just find me or just tweet me or whatever in case you come up with some questions for Jack you can even find him so let's move on to our next presenter he is a a a a a a a a a a a a a a