You know, I think one thing that's very tough when you're learning how to code well is that many of the examples just don't really equate to real life, right? So imagine this. I have a SubscriptionsController. Somebody is going to subscribe to your site. Now maybe a tutorial you read would have something like this. User::create(['name' => 'John', 'plan' => 'monthly']); You get the basic idea, right? They're very, very basic because they kind of need to be. A tutorial can't account for your specific scenario. And the more complicated you get in the tutorial, well, the more difficult it is to follow along, right? So as a teacher, it's very difficult to walk that line and figure out how complex should I really go to demonstrate this. So anyways, what you might find in real life is this.

So as a teacher, it's very difficult to walk that line and figure out how complex should I really go to demonstrate this. So anyways, what you might find in real life is this. You can subscribe a User in many different ways, or you can register a User in multiple different ways. So when you come to the store method, yeah, no longer is it just a quick call to User::create. You end up having to do all these checks to figure out how you should proceed, like this. So we'll say sign up the User. But we decide that in some cases, and very much like Laracasts, in fact, in some cases, we are signing up the User for a form account. And we'll say, but do they want a... Okay, so maybe they want a form account, in which case we don't have to go through Stripe.

So think of it like this. Step one for this would be to identify a point of flexibility. That's kind of worded badly, but I think that makes sense. So figure out some point in the code where you can be flexible in how you proceed and you have different strategies for how you proceed. The next step, and these aren't like official guidelines. It's just how I'm going to describe it to you. The next step would be to extract each strategy into its own class. Next, step three, ensure that each of those strategies adheres to a common API or really a common contract or an interface.

Next, step three, ensure that each of those strategies adheres to a common API or really a common contract or an interface. Now, whether or not you physically create that interface and you make each of the classes implement it, that's up to you. If you come from the Java world, it goes without saying. You're always going to do that. And even in PHP these days, a lot of people just default to that. I would never say you got to do it. If it makes sense and you have so many different strategies and you think that's useful, then do it.

Yeah, I think that'll do nicely. Okay, so let's figure this out together. Step 1, identify a point of flexibility. Okay, well, we already had those. I'm going to paste those in here. Step 2, extract each strategy into its own class. All right, let's do that. Now, here's how I like to name these. For each strategy, it's basically going to correspond to how you speak it. So if this first option registers a ForumUser,

For each strategy, it's basically going to correspond to how you speak it. So if this first option registers a ForumUser, I might say registers ForumUser. And that's fine. No problem there. Specifically and directly describes this particular strategy. Class RegistersForumUser. Okay, next we have one to register a regular user. So registers, how about just registers User? Or how about registers Subscriber? Because that's really what it is.

Or how about registersSubscriber? Because that's really what it is. All right. What else? registersTeamMember. All right, registersTeamMember. Paste that in. And then finally one more to registersForeverUser. So registersForeverUser. Or lifetimeMember.

So registers forever User. Or lifetime member. Maybe that. Registers lifetime member. Paste that in. Registers lifetime member. All right, so looking good here. We have four different classes for the point of flexibility. So we've taken care of Step 2. Done.

So we've taken care of Step 2. Done. Let's move on. Step 3. Ensure that each of those strategies adheres to a common contract. And all that means, it's fancy talk for saying make sure they all can respond to the same method. Like this. So regardless of which strategy you choose, you can call the same method. There we go. Makes sense?

There we go. Makes sense? All right, so we've taken care of this one. Finally, Step 4. Determine the proper strategy and let it handle the task. Okay, so this final step, you're basically just kind of doing a factory or something. As you'll find for a lot of these patterns, they all just kind of circle around the same idea. If you really dig into, for example, SOLID, the SOLID principles. Each of those letters, yeah, they all kind of circle around the same thing. So if you feel like there's overlap, you're right.

Each of those letters, yeah, they all kind of circle around the same thing. So if you feel like there's overlap, you're right. There is a lot of overlap. Okay, determine the proper strategy and let it handle the task. So you could even do something like this. You could call a method and you could name it exactly that. getRegistrationStrategy. Do whatever you need to do to figure out the proper strategy for registering this User. So getRegistrationStrategy. Now, we're not testing this.

So GetRegistrationStrategy. Now, we're not testing this. We don't have anything to run here. It's just a scratch file. But maybe you would accept the request. Maybe we'll pass that through here. Okay, so yeah, maybe your check is something like if the requestedPlan by the User is forever, well, in that case, we're going to return an instance of RegistersLifetimeMember. All right, so return new RegistersLifetimeMember. Next, maybe you check to see if request, I don't know,

All right, so return new RegistersLifetimeMember. Next, maybe you check to see if $request, I don't know, maybe if there's like an invitation within the request parameters. In that case, we are registering a TeamMember. So new RegistersTeamMember. This is what I mean when I say it's basically just a little factory method here. Finally, I'm not going to bother doing the fourth one. But finally, by default, we will register a regular Subscriber. So you get the idea, right? You defer to a method that does whatever it needs to do to figure out which strategy we're going to implement.

So you get the idea, right? You defer to a method that does whatever it needs to do to figure out which strategy we're going to implement. Now, once you determine that strategy, all you do is new it up and return from the method. So now at this point, this will be your strategy. And what's the final step? Determine the proper strategy, done, and let it handle the task. So basically strategy, handle the task. And then yeah, you might want to pass through the request data or an array, whatever you want in that case. So now here, yeah, this would create the User, maybe process a single payment rather than a subscription and set the proper plan.

So now here, yeah, this would create the User, maybe process a single payment rather than a subscription and set the proper plan. Maybe this one, it doesn't bill them. It simply creates a basic account and assigns a teamID to them. registerSubscriber would basically subscribe them in the usual way. And then registerForumUser doesn't bill, doesn't give them subscription access at all. It just creates a basic account that allows them to participate in the forum. Four different strategies for accomplishing one goal. So when you're ready to sign them up, you determine the strategy, and then you let that particular strategy handle the request.

In this case, we found four. Or really, one point of flexibility with four different strategies. Step number two, extract each of those strategies into its own class like we did here. Three, ensure that each of those strategies adheres to a common interface, and we did. Each one has a handle method. Now like I said, if you decide that you're going to create a contract here called RegistersUser or something like that, and that contract has a handle method on it, yeah, I mean, that's fine. Do whatever you want to do there. My only point for excluding that is sometimes people get it in their head.