Let's move on to another strategy that you might consider, and this is actually one you'll see across Laravel quite a bit, so I'll show you a couple of examples. So yeah, imagine you have some kind of class, and within a certain method, as it turns out, there's like 12 different things you need to do, right? From my experiences, figuring out how to do that is one of the hardest things. It's a big hurdle you got to get over. So generally, you start out by creating a very large method. It's a hundred lines. You're ashamed. You're still kind of from your procedural background, and you don't know what to do. That's okay. It's the first step for everyone. Then, maybe you're starting to learn about object-oriented programming, and you don't really understand it, but you do understand that you can take this procedural code you had before and move it into a class, and the reality is it's still procedural, but you're kind of on your way.

even though we said there might be 10 or 15 or whatever. You sometimes run into these situations. There's just so many different things that have to be done when this particular action takes place. So we're not going to put it all in the single function. We're not going to create other methods. That's good for small stuff. So if we only had two or maybe three things, and there's not too much logic involved, that's a good choice. But once we get to the point where there's like 10 different things, here's what you can do instead. Each action gets its own class. So we would have class do this, and you name the class exactly how you would describe the action that is taking place. So that might be one. The add foo to bar might be another one. And then the run something class, just as a final example, would be its own class as well. Next, step two. Each of these classes needs to adhere to some kind of contract. And that doesn't mean you have to create an interface.

class, just as a final example, would be its own class as well. Next, step two. Each of these classes needs to adhere to some kind of contract. And that doesn't mean you have to create an interface. If you want to, and it makes you feel better, great, that's fine. But otherwise, just assume that each one should offer the same method. And maybe that method is handle. Fair enough. Pretty common. So now every single one of these classes, all 10 of them, or five in this case, all of them will offer a handle method that will execute the given action. Still on board with me? Cool. So now that you have these classes, you can build up an array of them, such as $tasks = array(). And now each item in the array will be the class path. So something like this, like this, or of course, you could do the full path, like so. So yeah, let's grab all of these, remove the comments, and then finally get the full path, like so. And we should add commas. So now we have a sequence of tasks that

could do the full path, like so. So yeah, let's grab all of these, remove the comments, and then finally get the full path, like so. And we should add commas. So now we have a sequence of tasks that need to be performed. The only remaining step is to perform them. For each task, new up the class and call the proper method. And in this case, the method would be handle. New, task, handle. And then of course, pass through anything that they might need. But this is probably fine. Kind of cool, right? If you've never considered this, in some cases, it's a good approach to consider. So now all of these classes would go within the same folder that corresponds to what you're trying to do here. And then once again, they offer a handle method where they execute one piece of the puzzle. And now this is going to be, trust me, light years easier to maintain than some massive method or even breaking it down into a few methods. And further, when anyone else comes on your team,

call this the chain of responsibility pattern. It's not quite all the way there, but there are some building blocks of that pattern. At the end of the day, though, who really cares? It's a nice approach to consider. So let's switch over and review two different examples specifically from Laravel. Now we'll start with the core framework itself. And then we'll switch over to Laravel Spark. I got a good example for you there. Okay, so let's take a look at this. Here's the entry point, in fact, for Laravel. So this is the main index.php file. Very quickly, I'm going to take you to where we want to go. So we bootstrap the app. We then resolve the main Kernel class out of the container. And we call a handle method on it. Okay, so let's take a look at that. Let's go to the Kernel class. And well, yes, we have our Kernel class that you can modify. And this is where you have your middleware and your route middleware. But we actually want to go to the parent. So I'm

the Kernel class. And well, yes, we have our Kernel class that you can modify. And this is where you have your middleware and your route middleware. But we actually want to go to the parent. So I'm going to go to Foundation\Http\Kernel. All right, so let's take a look at that handle method. Now, once again, don't worry about this too much. But the part I want you to take a look at is here. We take the request and we send it through the router. So if we review that, notice there's this one section right here. So as you can imagine, when you're bootstrapping a framework, once again, there's so many different things that need to be done. And it's kind of tough to figure out where all of that code does. When you literally have 15 different things, you start up the session, you set the errors variable so that it's available in every view, like you know with Laravel. There's lots of little things like that. And if you're not

different things, you start up the session, you set the errors variable so that it's available in every view, like you know with Laravel. There's lots of little things like that. And if you're not careful, and you put it all in one class, it gets muddy really, really fast. So let's go to that bootstrap method. And then we see right here, this app bootstrap with the bootstrappers. Okay, well, what do the bootstrappers look like? That's returning a property. Let's go to the property. Okay, well, this looks really similar to what we had before, right? Let's go back real quick. Yeah, it's an array of class paths. Okay, so if we switch back, next, notice this is exactly what we were talking about earlier. Each class has a name that corresponds to the task or action that is taking place. So some of the bootstrapping required for the framework is we got to figure out what environment you're in, we have to load your configuration, we have to handle exceptions,

just an example. Let's do one final one. How about boot providers? Okay, well, this simply defers to a boot method on the application. And here is where we walk over all of the service providers and boot them up. Okay, so now we can see we have an array of classes, each which implements a common method called bootstrap. But now at what point do these get loaded? Well, don't forget, if we go to that send request through router, we then call the bootstrap method. And then we fetch that array of bootstrappers and pass that to bootstrap with. And now there we go, here's our foreach. Now in this case, we fire a couple of events as well. But yeah, if we break that down, this is exactly what we had before. For each item within that array, or each class, new up the class, the make method for Laravel will resolve it out of the container and pass in any dependencies it needs. But ultimately, that's basically this on steroids,

for each class, new up the class, the make method for Laravel will resolve it out of the container and pass in any dependencies it needs. But ultimately, that's basically this on steroids, new up the class, and then call the common method. So if we come back to our scratchpad here, define an array, filter through them, and then new up the task and call the common method. Okay, let's review one more example. And then we'll call it a day. This one is related to Laravel Spark installer. Spark is a premium tool for building websites and handling team management and reporting and billing and all of that stuff. Anyways, you don't need to know any of that. But if we take a look at this new command, let's see what happens. So this is what would be triggered. For example, when you say spark new my-new-app, okay, it triggers a new command. Now what I want you to see is right down here. So we execute the command. And once again,

triggered. For example, when you say spark new my-new-app, okay, it triggers a new command. Now what I want you to see is right down here. So we execute the command. And once again, looks pretty familiar, right? exact same thing at play here. So we can see as you can probably guess, when you create a new spark application, there's all of these different things that need to take place. So you build up the Laravel project, you download spark from GitHub, presumably, you update the composer file, and maybe that appends to the file or does a search and replace. We update composer, we update a configuration file, we run a command, we run npm install, we trigger gulp, all of those different actions that need to take place. So imagine if we try to take all of this functionality, and we just put it directly within the command class here, it would kind of suck, right? And further, once again, it wouldn't easily describe what's going.

take all of this functionality, and we just put it directly within the Command class here, it would kind of suck, right? And further, once again, it wouldn't easily describe what's going on. But now with this approach, anyone can understand each step of the process. So we define an array of installers, we filter through them, we new up the installer. And in this case, the common method for each is called install. Alright, so I hope you have one new technique in your tool belt. In the next lesson, I'll show you another.