Back

Best Practices: Interfaces+Traits or Same Class Properties


This is one of the biggest conundrums that I face whenever I am extending my company's internal micro PHP framework on top of Laravel.

An example scenario would be, for example, a feature is being added which automates cascade delete through the Eloquent ORM.

Now many of the ORM features can be tweaked through use of properties on the model. Few of those configurations have an explicit interface or trait or combination of both required.

I had a hard time justifying the overhead for the devs to actually attach an interface to get the relations to be deleted and include a bootable trait to handle the deletion event logic.

Alternately the devs suggested that I just put the logic in the extended base model class and define a property to store the relations to be deleted. So as to conform with the already established scheme for the ORM.

Though I am of the view that interfaces in this case serve as a more visible and accountable way to add the needed functions for a feature to work. They also reduce bug chances in some cases. While the traits serve to separate the feature logic from the class.

Can someone advise through their experience? Or the currently accepted Laravel way?


Sign in to participate in this thread!



We'd like to thank these amazing companies for supporting us