"Prefer composition over inheritance": Why you don't use traits?

[piotrplenik]

"Prefer composition over inheritance": Why you don't use traits?

[peter-gribanov]

In example Prefer composition over inheritance EmployeeTaxData plays the role of ValueObject more than extensions of functionality.

There are no examples of Traits because there are very few normal cases when Traits are really necessary and have an advantage over other implementations.

I know just a few such examples:

• Symfony ContainerAwareTrait for inject Container in any services;
• Aggregates of domain events AggregateEventsTrait and AggregateEventsRaiseInSelfTrait.

These are very specific examples, not everyone understands and not everyone needs. In my opinion, they are too complicated for this guide.

Can you give a simple example that will be really useful, and not Trait for the sake of Trait?

[vidic-igor]

The new Symfony Clock component, has good use case for trait implementation.

Instead of having a dependency injection for each service you want to make "clock aware", you can just extend it by using a trait (ClockAwareTrait).

also all test that are required to be "time senstive" aka. aware of the clock in order for it to be mocked inside test, you don't need to extend the test case with a base class or write it from scratch each time, you can just use a trait (ClockSensitiveTrait) in order to reuse and set the clock for each test that needs it.

[peter-gribanov]

@vidic-igor ClockAwareTrait is just an example of bad practice in using traits.