Traits to DRY or unnecessary coupling?

[tulik]

I would suggest keeping these properties to the Infrastructure layer as a part of abstraction instead.

[matt-usurp]

The traits just implement the interfaces, there is nothing special about them.
There is nothing here that relates to infrastructure?

[tulik]

There is nothing here that relates to the domain. I would place them in Infrastructure/Domain/Entity namespace.

Quick reference:
https://github.com/Trismegiste/Are-Php-Traits-Good-Or-Evil#trait--the-bad-part

To Consider:
It may be a better idea to use abstraction in certain places instead.

It is just a suggestion because each case is different. I would be just careful here. You doing an amazing job 👍 sharing the common parts.

[matt-usurp]

Yeah, so I am not a fan of traits and only supply them because they allow a unique use case with doctrine annotations. Otherwise, I would typically have them re-defined in all use cases. I do not use inheritance much these days as I prefer to use composition.

Anyway a use case for the traits that might not be clear:

trait MyDoctrineCreatedAtTrait {
  use UmberCreatedAtTrait;

  /**
   * @ORM\Column(..)
   */
  protected $createdAt;
}

I wouldn't recommend it but its something that can save you writing the getters/setters again.

It would not be possible for me to supply base classes for all 5 traits that are in this package and the end user be able to consume all 5. They would still need to make their own abstraction class and then satisfy the interfaces. I think this is the biggest reason they exist. Be aware that you do not need to use the traits and I personally do not use them, its just not worth removing them as they might bring convenience to someone.

[tulik]

If trait example could be implemented as:

/**
 * @ORM\MappedSuperclass
 */
abstract class AbstractEntity implements EntityInterface
{
    /**
     * @ORM\Column(...)
     */
    protected $createdAt;
}

/**
 * @ORM\Entity
 */
class UmberEntity extends AbstractEntity
{
    // protected $createdAt inherited
}

I can't find any use case for unique annotation in this example. In other common properties, it can be a good idea to follow a similar pattern.

In a simple use case developer may need its entity to

Maintainability pitfall

/**
 * @ORM\Entity
 */
class TraitsBasedEntity implements CreatedAtAwareInterface, UpdatedAtAwareInterface, DeletedAwareInterface
{
    use CreatedAtAwareTrait;
    use UpdatedAtAwareTrait;
    use DeletedAtAwareTrait;
}

class AbstractEntity implements EntityInterface
{
    // Implementation just as in traits
}

class AbstractionBasedEntity extends AbstractEntity
{
}

Solution	Eff. Coupling	Maintainability Idx	Diffuculty	Bugg
Based on Traits	620.86	60.86	2.93	0.07
Based on Abstraction	52.98	78.15	1.29	0.01

Calculation based on PhpMetrics

[tulik]

I did wrong here mixing Eff (Efford) with EC (Efferent Coupling).