A few days ago, I was listening to a new podcast called 20% Time. It's a good one. You should check it out. They talk about a lot of Laravel stuff. But specifically, they came to the subject of model traits. And as I understand it, the impetus came from one of the episodes at Laracast in our Monstrous Code series on cleaning up a God object through the use of traits, and specifically, single-use traits. Now, this is the sort of thing that can offend a lot of people, so I'm going to show you the workflow, show you an example, and then you can make up your own mind. So take a look at this Thread class. We have basic stuff like scopes and some relationships. But if I scroll to the very bottom, you'll see that we have some methods related to the fact that a thread can be subscribed to. So for example, you subscribe to a thread, and now you're notified every time a new reply comes in. So we can see we have one, two, three,

that a thread can be subscribed to. So for example, you subscribe to a thread, and now you're notified every time a new reply comes in. So we can see we have one, two, three, four methods dedicated to this feature. Now, we have two options. One, leave it as it is. In editors like Sublime or Atom, it makes it really easy to find these. Another option, though, is to extract these into a trait, even if it's a single-use trait, and then we assign a readable name to the class. So let's see what that might look like. In my app directory, I'm going to create a new trait here, and we want to give it a readable name. So if a thread can have subscriptions, maybe it could be something as simple as hasSubscriptions, or Subscribable, or canBeSubscribedTo, anything you want, any convention you want to follow. So we'll create that, and now take a look. I'm going to switch back to Thread, and I will say

or can be subscribed to, anything you want, any convention you want to follow. So we'll create that, and now take a look. I'm going to switch back to Thread, and I will say this Thread uses hasSubscriptions. So now I can take those methods and push them onto the trait. subscribe, unsubscribe, subscriptions, and our custom accessor, and we'll do our refactor. All right, so take a look. Those methods have now been moved to this dedicated trait. And yes, it is true, it's probably a single-use trait, but in my mind, it's still useful. Once again, we've taken these related methods, and we've moved them to a trait, and now we can take that bit of functionality and assign it a readable name. So I think it's useful, but I am going to close by giving you two of the reasons people say it's not a good approach, and you can measure that for yourself. One, the idea is if you extract all these traits,

but I am going to close by giving you two of the reasons people say it's not a good approach, and you can measure that for yourself. One, the Idea is if you extract all these traits, you're just kind of tucking everything under the rug. So yes, you could have a class that uses six different traits, and it looks really nice and pretty, but that still ends up being 50 plus methods, and that can be a big signal that maybe you're missing something. So that's why people say you're sweeping it under the rug. Another argument against using them is if you use an editor like Sublime, they're not intelligent enough to, when you're searching for methods or symbols within a class, it's generally not smart enough to look in all of your traits and make them immediately accessible. So in Sublime, if I were to look for subscriptions, it won't find it. But if you use something like PhpStorm, like you see here, that's very much