Here's the thing. Any developer who has worked on a product or an application for more than a year, and you've seen it through, there's a very, very high chance that your User class will turn into a massive monster god object. So what exactly is a god object? It's exactly what you would think. It's a huge class that just does way too much. And generally, your User class is the first victim. And that's because when you think about it, a User can kind of do anything. So it always makes sense to attach the action to the User. For example, if you can subscribe to a blog article, then you might add a subscribeTo method, right? But then you also might want to do the inverse. So you would say unsubscribeFrom. Okay, well, there's one piece of functionality that makes sense. What about another one? Maybe you want to get the number of completions the User has. So something like completionsCount or completionCount. That would fit there. What else?

sense. What about another one? Maybe you want to get the number of completions the user has. So something like completionsCount or completionCount. That would fit there. What else? Maybe a user can start a formConversation. So startConversation. Yeah, as you can see, over the course of a year or more, the tendency for things like this to creep in is very, very high. And a handful of them are fine. It makes perfect sense. It's readable. It's intuitive. But yeah, once you have 50 or 60 or 70 of those in the class, things get kind of tricky. So most developers are very familiar with this. Okay, so over the next handful of videos, I'm not sure how many, we'll review different options you might refer to. Okay, so how about this one? Let's start somewhat simply. Imagine that you want an easy way to figure out the number of favorites a user has. And maybe that references a relationship like returnThis, favorites, count, or something like

somewhat simply. Imagine that you want an easy way to figure out the number of favorites a User has. And maybe that references a relationship like returnThis, favorites, count, or something like that. Now, we don't have a full project here, so I'm going to stub all of this stuff out. But you get the basic idea, right? But then later you decide, well, I'd like to do the same thing with their completions. Okay, well, once again, you reference that relationship, which I will hardcode. And then, obviously, I'm using Laracasts examples here. Maybe you want to fetch the user's experiencePoints or something like that. And that'll reference a relationship, which I will stub out. Yeah, once again, a couple are fine. But already right off the bat, the User class is growing and growing. So now imagine what it's going to look like in two years when I keep adding more and more of these, right? Okay, so if you're in that position, here's a very simple technique

and growing. So now imagine what it's going to look like in two years when I keep adding more and more of these, right? Okay, so if you're in that position, here's a very simple technique you might implement. If we take a look at these, they all sort of represent statistics, right? The number of favorites a User has, the number of completions, and the number of experience points. So if they all fit under this umbrella of a stat or a statistic, maybe instead we could add a single method called stats, and that can then defer to a different class. So, for example, I could return new Stats and then pass through the $user object. Okay, let's create that, app/Stats.php. And let's see, we have namespace App for the time being and class Stats. Okay, so the constructor will accept the $user, which I will assign. And now if I go back, any of these methods, all three of those, can now be nested there. So let's come back,

so the constructor will accept the User, which I will assign. And now if I go back, any of these methods, all three of those, can now be nested there. So let's come back, and I'll paste those in. And now count is a little redundant. So I can say stats, favorites, and then stats, completions. Finally, experience, yeah, that can stay the same. Okay, so this is one technique you can implement. We add a single method to our User that defers to another class that can be responsible for those sorts of things. And on the condition that this other class needs access to the User object, we pass a reference through the constructor. And that way, yeah, you can still do things like this, user, if you need to reference a relationship like that, any of this will be fine. You have access to that. So let's try it out. php artisan tinker. And in our case, yeah, I can just new up a dummy User here, since we're not actually pulling

like that, any of this will be fine. You have access to that. So let's try it out. php artisan tinker. And in our case, yeah, I can just new up a dummy User here, since we're not actually pulling from the database, like you would in real life. But anyways, before, you would do something like favoritesCount, or experience. But now we have that isolated behind a stats object. So instead, you can say user->stats->experience, and that'll give you your number, or favoritesCount, or your completionsCount. So yeah, that's one technique you can implement to clean up a User object.