Pentru ca nu ai de ales. Pentru ca in SUT e hardcoded linia use company\mytrait - o linie la fel de inocenta ca apelurile statice de “metode”.
Vrei sa testezi fiecare clasa in parte pentru a putea identifica vinovatul in cazul unui bug.
In acelasi mod, daca ai strica HttpKernel-ul toate integration tests ar pica. Daca strici middleware de login, toate testele pica.
Si asa mai departe. Orice e mai in fata in acel chain pica.
Ai spus ca se violeaza SOLID de catre un use case real, dar ai refuzat sa oferi o alternativa viabila ca sa putem dezbate si downsides-urile pe care acea alternativa le aduce.
De aceea lucram pe un use case real, pentru ca altfel ducem aceeasi conversatie stupida pe care au dus-o Taylor si Anthony pe twitter. Fiecare tinandu-si parerea, avand ceva diferit in mana lui.
SCP este perfect respectat. Controllerul isi are scopul lui, trait-ul importa o metoda cu un scop clar definit, repository-ul isi pastreaza acelasi continut ca in cazul trecut, fara traits.
Unde vezi violarea SCP in acel use case?
Inteleg insa violarea DI. A fost un downside pe care a trebuit sa ni-l asumam. Din fericire, metodele din controllere nu fac scopul unui refactor si nu au nevoie de abstractizari atat de amanuntite.
Cel putin, noi inca nu am ajuns sa suportam consecintele acestui downside.
Nu caut metode sa implementeze cat mai multe design patterns ci metode care violeaza cat mai putine si introduc cat mai putin overhead, atat pentru mine cat si pentru colegii care mai lucreaza la proiect.
Recomand cartea http://shop.oreilly.com/product/0636920033868.do daca nu o cititi pe toata, macar capitolul 2, explica si Traits cu exemple.
1 Like