The pitfalls of using traits
Tags: php, beginners
Published: 2022-10-10 19:32:00

When traits came to PHP, I'm sure many (myself included) thought they were a viable solution for code reuse. They offered ways to reduce code verbosity. They were easy to grasp. Suddenly we needed not to duplicate code across unrelated classes. 🤩 However, many (myself included) sobered after a hard lesson...


## What are traits in PHP

In simple terms, a _trait_ is a piece of code that gets copy-pasted into a class using it.
You can read what the [PHP Manual] says about traits if you are not familiar with them.


## Traits came to my rescue

I had a bunch of classes that all needed the same: a `Logger`, a `Connection` and a `Serializer` instances (there were some other, it was about 6-8 such services IIRC). The constructors were bloated, there were ~50 lines of code just to assign these services to private props through a constructor, same comments, same everything, in every one of these classes...

With every query I would have to type `$this->connection->table('foo')->select(...)` and then `$this->serializer->serialize($result)` and whenever something needed logging `$this->logger->log(stuff)`.

Thinking of introducing base classes, are we? But my target classes were not all related, it would not have solved the issue, and, worse, base classes stink.

So I experimented with "bundles"... I would inject a single class to the constructors, but then needed to type this kind of code `$this->bundle->logger->log(stuff)` 🤦‍♂️.

Instead, I discovered with traits I could type just `$this->log(stuff)`, `$this->select(...)` or `$this->serialize($result)`.

It was easy to write a trait with those methods, like this
```php
protected function select(...$args) {
    return $this->connection
        ->use($this->database)
        ->table($this->table)
        ->select(...$args);
}

public function injectConnection(Connection $c){
    $this->connection = $c;
}
```
There was some magic calling the setter automagically on startup.

I could even combine multiple such traits to create shortcuts to several services.

A perfect solution.
Except...


### Except...

So... How do you test a trait? Well, you don't! You can't instantiate it, you test a class that uses the trait.
How do you know a class is using a trait, so that you can test it? Well, you don't[^ref]!
See the problem?


### Except...

What about dependencies? You create a fancy class with half a dozen traits and as many services that you need to inject, somehow, and you end up with boilerplate code nevertheless.
Worse, you create hidden dependences. And wait for the moment you start combining traits into supertraits.


## Takeaway

Think twice before creating and/or using a trait. I dare say, in most cases, if you need a trait, something in the class design has to smell.

Remember that using a trait is just copy-pasting code that could otherwise sit in a proper class.

Use class _composition_ instead of traits. Use DI containers with autowiring capabilities to reduce boilerplate. Understand that typing a couple of characters extra is cheaper than dealing with tangled dependencies and trait conflicts.
In fact, those "bundles" I mentioned earlier, if executed correctly[^int], are the way to go in many cases.

Traits are a valid language construct, though. Do use them where applicable. Make a conscious choice and be content with it.


<!-- refs -->
[PHP Manual]: https://www.php.net/manual/en/language.oop5.traits.php

[^ref]: Unless you inspect the source or use reflection.
[^int]: Yes, I mean interfaces.