Orice unitate trebuie sa-si poata indeplini responsabilitatea singura, iar un trait este o unitate.
Daca ai nevoie de acea restrictie, inseamna ca ai nevoie de apelarea lui $this->metodaDinInterfata(), desi metodaDinInterfata nu se afla in unitatea respectiva (in trait).
Deci violeaza SRP. Pana sa ataci acest punct, citeste in continuare si ataca intregul raspuns
Daca ai acea nevoie de a apela medodaDinInterfata(), te gandesti la OCP si faci un sistem de plugin, iar pe trait il transformi in clasa care implementeaza interfata comuna tuturor pluginurilor.
Sistemul de pluginuri (sistemul de atasare / inlaturare a unui plugin) astfel rezultat il poti muta intr-un nou trait, dar ceea ce a fost trait cu acel apel la metodaDinInterfata() devine plugin.
Adica muti totul cu un nivel de abstractizare mai sus, si codul devine intuitiv w.r.t. SOLID (atat SRP, cat si OCP).
Observi ca un astfel de trait ar fi ciudat si atunci cand incerci sa-l testezi, pentru ca iti cere sa creezi metode noi in test double - daca vrei sa faci unit testing pentru trait.
Violeaza si DI, deoarece cu un trait (linia aia inocenta “use Trait”) importa behaviour strain in clasa actuala, insa acest behaviour nu poate fi alterat, e fix, hardcoded, la fel ca apelurile la new sau apelurile statice la metode. Adica: in loc sa ii dai unei clase dependintele (DI), ii spui clasei sa si le traga singura de fiecare data cand folosesti un trait.
D-aia zic, cand faci TDD si respecti SOLID, rareori vei simti nevoia de traits. Foarte rar.