So here's where we left off in the previous episode. We wrote three tests to prove that when a Thread is created, the User earns points. When a reply is left, the User earns points. And when a Thread owner marks a reply as the best one, that reply's owner once again receives a lot more points. So everything's passing, but if you think about it, imagine somebody new joins your team in six months, and they're just trying to figure out, okay, how does reputation work? On what conditions does a person earn or accrue reputation? At the moment, this is basically it. And even this isn't clear. We have some magic numbers that we know what they mean, and the new developer can parse it, but it's just not very clear. It's very implicit at the moment. And yes, they could go to Thread, and let's say mark. Yeah, they would just have to hunt through and say, oh, okay, here it looks like 50 points is awarded, or here 10 points is awarded. But

And yes, they could go to Thread, and let's say Mark. Yeah, they would just have to hunt through and say, oh, okay, here it looks like 50 points is awarded, or here 10 points is awarded. But they have to know where to look. You know what I mean? It gets very confusing. So it would be nice if we could take this concept of reputation and at least elevate it to a first-class citizen. Why don't we do that? In my app directory, I'm going to have reputation.php. This is just going to be a Polo here. However, now think about it. We could declare some constants for these point values. How about threadWasPublished is worth 10 points? Another one, replyWasPosted is worth 2 points. And then finally, bestReplyAwarded, and we're going to say that's worth 50 points. So now think about it. We have a single source of truth for figuring out what all the different reputation types and values are. And if you ever need to change it, you don't have to hunt in

So now think about it. We have a single source of truth for figuring out what all the different reputation types and values are. And if you ever need to change it, you don't have to hunt in thread.php or some event listener. You go to a single file to adjust everything. All right. Next, maybe we have an award method on this where we accept the number of points, and then we could say, hmm, we need a User. So we could either accept the User through the constructor. We're just kind of riffing on the fly here. We're thinking on the fly. Or maybe, hmm, if this were a facade, you could say award this User 20 points. Or you could also say reputation reply posted. You know, that's what we're going to end up doing there. That's not horrible. So award the User the given number of points. Okay. Then I could say User increment reputation by the given number of points. Let's give this a shot. So I'm going to go to our main

not horrible. So award the User the given number of points. Okay. Then I could say User increment reputation by the given number of points. Let's give this a shot. So I'm going to go to our main feature test here, and we'll focus only on this one. A User earns points when they create a thread. So if we run that, right now, it does return green because we haven't even referenced that new class. So let's see. Right there. Yeah. If I were to comment that out and rerun the test, it's going to fail. Now, one thing we could do if we were to call this is rather than hard coding 10, which once again is sort of a magic number, you could say reputation and we want thread was published. So now we don't have to reference a specific number. We can reference a constant that represents that number. And we would still get green in that case. We could also say reputation. We could even do a real-time facade. So if you're not familiar, if you proceed your

that represents that number. And we would still get green in that case. We could also say reputation. We could even do a real-time facade. So if you're not familiar, if you proceed your class with facades, you start the namespace with that, you can interact with it as if it was a Laravel facade. So that means I could say something like reputation award the thread's creator with 10 points. We get green. Or once again, reputation thread was published. And run that. Undefined class constant. Oh, you know what? This is going to be a downside to using the real-time facade. Okay. You know what? Let's just stick with not using a real-time facade. And instead, we could say new reputation award the thread's creator with this representation of the point value. And we do get green. It's a small change. But remember, the real value is that we now have a single source of truth for declaring how much these points are worth. Otherwise, we

maybe it is better that we're more explicit here. We're hiding how we increment the reputation, and just being a little more clear. Reputation should be awarded to the thread's creator. Now, what we could also do at some point, if we want, is if we end up with, again, 10 different places where we award reputation like this, we could set up something like an event subscriber, where you have a single class, you listen for various events, and then you award reputation as a result of that, rather than doing it here. That's something to think about a little bit. It does complicate the code, I would say, unnecessarily so at this point. You end up having to create an event for every single action, you got to listen for that event, you have to respond to it. But nonetheless, we may reach for that if we need to. Okay, let's go back to reputationTest and run the second one. This is for a User earns points

you have to respond to it. But nonetheless, we may reach for that if we need to. Okay, let's go back to reputation test and run the second one. This is for a User earns points when they reply to a thread. Okay, so right now, here is where we do it. We're not going to change this new reputation and award the replies owner by reputation reply posted. And we still get green. Oh, and by the way, another tiny benefit to this is, at the moment, we're handling the awarding of reputation by just incrementing a point value. But like I said later, we might have a table where we record a timeline of every single event that takes place. And then ultimately, we calculate a sum of all of those events to calculate their reputation. If we decide to change that, we only have to update this operation here, rather than, once again, 10 different files where we call incrementReputation. Okay, anyways, we have one more.

change that, we only have to update this operation here, rather than, once again, 10 different files where we call incrementReputation. Okay, anyways, we have one more. Everything's passing. But on Thread, you'll see right here, we reference that magic number again. So if we remove it, let's do this reputation test. Let's go ahead and run everything. Yeah, now it's failing. So if we come back, new reputation awarded to the replies owner, and the amount of reputation best reply awarded, run it awarded. Oh, sorry. Okay. Run that again. And now we do get green. Finally, if we close everything out, we can now see we have a single class that's responsible for declaring and awarding reputation to a given User. If we take a look at GitHub, here are the changes we made here and the Reputation class. Now, actually, on that note, though, this could be static if we want. I can't think of any side

If we take a look at GitHub, here are the changes we made here and the Reputation class. Now, actually, on that note, though, this could be static if we want. I can't think of any side effects. So if we wanted to do that, let's see, we could shorten this. And then in the boot method, the same thing here. Finally, in reply. So notice, we're able to make these changes with quite a bit of confidence because we have those tests. So if at any point, we had a brain freeze, and we made some mistake, well, it doesn't matter, we run the test, and we would instantly see, oh, you, oh, you made some kind of stupid typo, it'll pick up on that instantly. Okay. Anyways, here's what we ended up with for this episode. In the next episode, we will display this reputation within our forum.