Alright, let's see if we can fit this into a few minutes. So we have a User class, and we have these four methods here. Now imagine a User has many more methods, and these aren't even together. They're just somewhere within the class. And we can see favoritesCount, watchLatersCount, completionsCount, experienceCount. Okay, so here's my tip to you. Learn to seek out common suffixes and prefixes within a method, like a hawk. So in this case, we start to see things related to the count, count, count, count, count. So often, when you find these repeated suffixes, what it really means is that some class is begging to be extracted.

So often, when you find these repeated suffixes, what it really means is that some class is begging to be extracted. So to figure out what that class is, let's try to break down what do these represent. So a User's favoritesCount, a User's watchLatersCount, they're all numbers. So they're sort of like the User's stats, right? When you think about it, you look at your stats, it shows you a graph of your favorites, your watchLaters, all that stuff. So why don't we take the implicit there, this idea of stats, and we're going to upgrade that to a first class citizen and make it explicit. So instead, you'll just create a plain old php object here called Stats.

that to a first class citizen and make it explicit. So instead, you'll just create a plain old PHP object here called stats. So now all of these can now be moved into the Stats class. And what you'll find is that when you do this good refactor, often the suffix that you had before then becomes redundant. So in User, it was important to be clear that we wanted a number, but now that they are nested within stats, it's kind of redundant. So we're going to get rid of that entirely, and this gets cleaned up nicely. So now though, it was nice before that I could just say userExperience, right? This is what we had before.

So now though, it was nice before that I could just say User experience, right? This is what we had before. Well, why don't we make it easy by saying User, give me their stats, and then I want their experience. I still think this is nice and clean. So if you want to allow for this API, well, let's just create a method here called stats. And all that's going to do is return a new instance of our new Stats class. And now we're going to pass, this is important, we're going to pass a reference to User itself. And this is kind of a cool pattern that I like to use. So we new up a class, and then we pass a reference to ourselves.

And this is kind of a cool pattern that I like to use. So we new up a class, and then we pass a reference to ourselves. So User passes a reference to itself to Stats. So now if we build this up, we'll accept that and initialize the fields. So now the benefit to this is if any of these methods need to call back into User to perform some kind of calculation, we'll just reference our user property here and send the necessary message. This is a nice system to get into. So the benefits to this is now all of these Stats related methods are no longer in User. So it helps to dissolve the God object that you might have been forming.

So the benefits to this is now all of these stats related methods are no longer in User. So it helps to dissolve the God object that you might have been forming. Instead, they all get replaced with a single method name called stats. And then further, before this was all implicit and scattered throughout a User class. But now they've all been grouped together, and we've assigned a readable name to that functionality.