In the previous episode, we learned how to combine the strategy and factory patterns to refactor a confusing bit of code related to how we register a user. And what we ended up with is a single factory method and three different strategies for how we register a user. But now I'd like to talk about this a bit further. And step one will be to put each of these in their own file. So I will cut this out, and then within my app directory, I'll create a new class called RegistersTeam, and I'm going to put this in a directory called UseCases. And we'll talk about that more in a bit. Okay, so I'll paste that in.

And we'll talk about that more in a bit. Okay, so I'll paste that in. Next, so as not to bore you, I will repeat that process behind the scenes two times. And there we go. So you'll now see we have three new classes, and at this point, I only need to import them. So we'll do that now. And there we go. Next, before we move on, as a quick aside here, I named this GetRegistrationStrategy mostly to be very clear that it is a factory method that returns which strategy we will choose.

A use case can be a neat approach for your application, and at the very least, it's a good tool to have in your belt. Think of each use case as one action a user can take, followed by all of the steps associated with that action. Or in other words, if this is an action a user can take, register a Team, well, here are all of the steps that are required in order to complete that action. Now here's what we'll do. We already have five comments here. Let's extract those into methods. createUser.

Let's extract those into methods. Create User. Create Team. And I think as part of that, we will handle inviting the team members. Then we need to record the payment. And then finally, we will send welcomeEmail. And there you go. So now at this point, you would simply give the class whatever data it needs. So for example, let's see. You can do whatever you want.

So for example, let's see. You can do whatever you want. Like if you want to send through the request attributes directly, that would be fine. Or if you only have a couple, you could do that. Or you could just pass in a new User instance that has not yet been persisted. And then we could initialize those. Okay, so now if that were the case, you could say, all right, we will save the User. And then create the team. You know, something like that. And here, maybe you will record the payment.

But you get the basic idea of the shape this might take. And actually here, we did say you'd have to invite the team. So here, maybe you have a method called invite. And then you would send through a list of email addresses of people to invite as part of that registration. Or that might be something you do as a separate request. Anyway, so that's what you end up with. And now, all of these just turn into methods or steps. createUser. createTeam.

Create User. Create Team. We do that as part of that, don't we? And then record Payment. And then finally, send welcomeEmail. So we end up with this or turn it into a fluent API and chain them. And there we go. Okay, get rid of all of that. And this is what we end up with. So a fairly simple use case for how we would register a Team.

And this is what we end up with. So a fairly simple use case for how we would register a Team. And what's cool is, you now have this directory that kind of describes all the different things your system can do, similar to a feature. So maybe another use case is maybe something like for Lericast, a User can purchase a Video. All right, well, what if you had a use case called PurchaseVideo? And that class within the handle method would have a series of steps that are necessary in order to purchase the Video. So it ends up being a fairly clean and more importantly, simple way to go about it. Other options you can sometimes consider are where it gets very indirect, like create a

So it ends up being a fairly clean and more importantly, simple way to go about it. Other options you can sometimes consider are where it gets very indirect, like create a User and then hook into the user created model event and then set up the Team and then fire or dispatch an event. Once that's done, and then you'll have a listener that will record the payment and then another listener that will fire off a welcome email. And listen, there's definitely examples where you want to do that. We've covered it all over Laracasts, but sometimes it's nice to encapsulate all of it into a single class that we'd refer to as a UseCase.

single class that we'd refer to as a use case.