Let's finish up by discussing responsibility. So if I visit the Trending class, here's where we determine and fetch all popular series. I don't love this though. Think about it. Why would a featured collection have awareness, or why should it have awareness, of how we track and record and store popular series on the site? Think of everything it knows. It knows that we use Redis. It knows that the key is series.popular. It knows what is returned from that command.

It knows that the key is series.popular. It knows what is returned from that command. It knows how to fetch those results. And then finally, it knows what to do with those results in order to keep the order. In fact, I think this could even be changed, but you get the idea. It's too much knowledge or responsibility or awareness, however you want to refer to it. So instead, what I'm really trying to say here is something like, if I were to write it out, give me TrendingLaricastSeries. But so often, this turns into that.

it out, give me TrendingLaricastSeries. But so often, this turns into that. So let's see if we can fix that. Give me return TrendingLaricastSeries. Could we just do that? Why not? All right, let's see if we can do it. I'm going to create a new class here called Laricast. There we go. We're going to add a static method for trending, and then I'll paste all of that in.

There we go. We're going to add a static method for trending, and then I'll paste all of that in. Okay, so now this doesn't change the fact that this class now has a little too much responsibility, but that's okay. We're pushing that responsibility up the chain where we can refactor it then. The important thing is my featured collection no longer needs to be aware of how we calculate that. And also notice, this means I can remove those imports, which is a good thing. There we go. Let's go ahead and run the tests.

Okay, exact same thing, we'll do one more. In progress, notice yet again, so much awareness. A featured collection has to know what the key is, has to know what the user's ID is. It has to know that we store it using Redis. It has to know what the command name is, what format it's returned in, and then how to make use of it. It's too much. Instead, a couple options, get the users in progress series. That would be fine. So you might start with like, get the currently authenticated users.

That would be fine. So you might start with like, get the currently authenticated User. Could be their series or in progress series. Or sometimes I try to avoid it a little bit, putting yet more things on User because your User model is always the thing that grows and grows and grows. So after five years, the likelihood that the User class is the most complicated is almost 100% often, or the top or the second most complicated thing usually. So another option would be maybe Series. Maybe this would go on seriesInProgress, and then you would accept the User where you could pass that through.

Maybe this would go on Series in progress four, and then you would accept the User where you could pass that through. So that maybe is another way you could do it. So we are reassigning this responsibility up a level to where it might be more relevant. Okay, run the code. That fails. So let's open up my Series model. I'll go to the very bottom. I'll just put it here. In progress for the given User.

I'll just put it here. In progress for the given User. And now I can take all of that code and move it here. I can update this code to the User instance like so. I can then use string interpolation. Now I still don't love that we're reaching into Redis here, but it's at least a little bit more appropriate than what we had earlier. So let's see, cross our fingers, and now that works as well. We've moved the responsibility up a level.