What are PHP Traits?

A Trait is simply a group of methods that you want include within another class. A Trait, like an abstract class, cannot be instantiated on it’s own.

An example of a Trait could be:

trait Sharable
{
    public function share($item)
    {
        return "share this item";
    }
}

You could then include this Trait within other classes like this:

class Post
{
    use Sharable;
}

class Comment
{
    use Sharable;
}

Now if you were to create new objects out of these classes you would find that they both have the share() method available:

$post = new Post();
echo $post->share(""); // 'share this item'

$comment = new Comment;
echo $comment->share(""); // 'share this item'

How do Traits work?

As you can see from the example above, both the Post and the Comment objects have the share() method available despite not having that method defined.

A Trait is basically just a way to “copy and paste” code during run time.

This means the Trait is copied in to the Post and Comment classes so when you instantiate a new instance, the share() method code will be available.

How are Traits different to Abstract classes?

A Trait is different to an Abstract class (What are Abstract classes?) because they do not rely on inheritance.

Imagine if the Post and the Comment class had to inherit from a AbstractSocial class. We are most likely going to want to do more than just share posts and comments on social media websites, so we’ll probably end up with a complicated inheritance tree like this:

class AbstractValidate extends AbstractCache
{
}

class AbstractSocial extends AbstractValidate
{
}

class Post extends AbstractSocial
{
}

This complicated inheritance is pretty nasty, but it also adds complication when a simpler object does not have a similar inherence structure. For example, if we had a Message object that shouldn’t allow social sharing, then this object would require a slightly different inheritance structure.

How are Traits different to Interfaces?

Traits kind of look a lot like Interfaces. Both Traits and interfaces are usually simple, concise and not much use without an actual implemented class. However the difference between the two is important.

An interface is a contract that says “this object is able to do this thing”, whereas a Trait is giving the object the ability to do the thing.

For example:

// Interface
interface Sociable
{
    public function like();
    public function share();
}

// Trait
trait Sharable
{
    public function share($item)
    {
        // share this item
    }
}

// Class
class Post implements Sociable
{
    use Sharable;

    public function like()
    {
        //
    }
}

In this example we have a Sociable interface that states that the Post object is able to like() and share().

The Sharable Trait implements the share() method and the like() method is implemented in the Post class.

So as you can see we could type hint the Post object to see if it is sociable (it implements the Sociable interface), whilst the Trait defines a reusable method that we can then mix in to other similar classes:

$post = new Post();

if ($post instanceof Sociable) {
    $post->share("hello world");
}

What are the benefits of Traits?

The benefit of using Traits is that you reduce code duplication whilst preventing complicated class inheritance that might not make sense within the context of your application.

This allows you to define simple Traits that are clear and concise and then mix in that functionality where appropriate.

What are the drawbacks of Traits?

However with that being said, there are possible drawbacks when using Traits too.

Traits make it very easy to write bloated classes that have too much responsibility. A Trait is essentially a way to “copy and paste” code between classes. By having a way to very simply add another group of methods to a class, it’s very easy to diverge from the single responsibility principle.

Other drawbacks to using Traits are not being able to see all the methods of a class when looking at the source code as well as method conflicts or duplication of logic.

I think Traits, when used correctly, are a fantastic tool to have at our disposal. However, Traits can also be crutch for lazy programming. It’s very easy to just add a Trait to solve your immediate problem. Often composition is the better approach over inheritance or using a Trait.

What are typical situations for using Traits?

So what would be a typical situation when using a Trait would be a good idea?

Well, I think Traits are an excellent way to reuse a chunk of code between a set of similar classes that should not inherit from the same abstract class.

Using the social application from earlier, imagine we had objects for Post, Photo, Note, Message and Link. For the most part, these objects are fairly interchangeable within our system as they are typically created and interacted with between users.

However, Post, Photo, Note and Link are all objects that are publicly shareable between users, whereas Message objects are private messages that are not made public.

The Post, Photo, Note and Link objects all implement a Shareable interface:

interface Shareable
{
    public function share();
}

Does it make sense to duplicate the share() method in every class that implements the Shareable interface?

No.

Does it make sense to have an AbstractShare class that objects who implement the Shareable interface extend?

No.

Does it make sense to have the share() method implemented as part of an AbstractEntity class, but then blocked out for the Message object?

No.

Does it make sense to implement a ShareableTrait that fulfils the interface contract and can therefore be easily added to only objects that require it?

Yes!

What is a real life example of using Traits?

When you first encounter Traits as another tool at your disposal, it can be difficult to know whether a situation should really call for using a Trait, or one of the many other possible solutions to solving this particular problem.

When you face this situation, I think it’s a really good idea to look to the world of Open Source to see how others have used this particular technique.

In my opinion, an Open Source project that makes good use of Traits is Laravel’s Cashier package.

The Cashier package adds functionality to your Eloquent models to make it really easy to manage subscriptions within your SaaS application.

However in order to add functionality to your existing models, you end up facing a predicament.

The first option is to simply implement the methods yourself by copy and pasting the method examples from the documentation. This isn’t a good solution because you might introduce bugs by copying the code incorrectly and whenever the Cashier package is updated you will have to go through all of your models and update your duplicated code.

A second option is to extend the Cashier object to inherit the methods that you need. This is also a bad solution because what happens if you want to add methods from a package that adds validation to your models? You will end up with a complicated lineage of inheritance that will make your code bloated and confusing when you, your colleagues, or your future self return to this code in the future.

Instead, the Cashier packages provides a Trait that allows you to add the functionality to any of models without duplicating the code yourself or having a nasty inheritance lineage:

use Laravel\Cashier\BillableTrait;
use Laravel\Cashier\BillableInterface;

class User extends Eloquent implements BillableInterface
{
    use BillableTrait;

    protected $dates = ["trial_ends_at", "subscription_ends_at"];
}

As similar excellent usage of a Trait is the Validating package also for Laravel’s Eloquent. This package allows you to create auto-validating models by including a Trait.

So as you can see, instead of extending the Cashier object to add the subscription methods, and then extending something like Magniloquent to add validation, you can simply add two Traits to your model. This prevents a crazy inheritance tree.

Conclusion

So the big question is, should you use Traits? I think you should definitely consider using Traits within your projects. Traits offer a really nice solution to the nasty mess of inheritance that can arise in single inheritance languages such as PHP.

Traits allow you to add functionality to your classes horizontally without over-complicating or duplicating code.

However, it is very easy to use Traits as a crutch. Traits are not the answer to all of your problems. Using a Trait in the wrong situation is most definitely a bad decision. If you are trying to crowbar the functionality you desire into a class using Traits, you are probably doing something wrong.

As with almost everything in computer programming, there is most definitely right and wrong situations to use certain components or patterns. A Trait might solve your immediate problem, but using composition might be the real answer to your predicament. Don’t look for situations to use Traits, instead try and choose the right tool from your tool belt when facing a problem. Understanding when and where to use Traits adds another weapon to your arsenal.