Da. Daca urmezi sistematic acest pattern, miroase deja a un inceput bun de anticorruption layer.
In JS e mai dificil sa vezi layerul, cel putin mie imi e dificil, deoarece e un limbaj prea “hackish”; nu ai interfete de exemplu, pentru a forta contracte de comunicare intre obiecte (in momentul compilarii, cum e in alte limbaje).
Mi-am editat primul raspuns:
Uite un exemplu la scara redusa despre care putem vorbi.
Sa zicem ca folosesti un wrapper pentru PDO in PHP. In mod clasic, ai avea un cod de genul
while($wrapper->fetch()) {
//do stuff
}Cu un layer, codul ar fi ceva de genul:
while($productRepository->getNext()) {
// do stuff
}Repository ar folosi intern acel wrapper (vendorul), deoarece el intr-adevar aduce momentan multe beneficii, dar nu vrem sa depindem direct de acel vendor.
Citirea o poti face cu consum optim de memorie folosind un generator. Overhead-ul este minim, si daca in viitor vrei sa schimbi vendorul, nu e nevoie sa modifici codul client (care depinde de Repository, nu de vendor direct), ci doar Repository-ul.
Acum introdu cate un Repository (cu o interfata comuna) pentru fiecare entitate cu valoare de business si ai un intreg layer. (Nota: nu e musai sa aiba valoare de business, dar daca urmezi DDD, este sanatos)
Sau cum ar zice Uncle Bob: vendorul e impachetat intr-un plug-in. Ma rog, doar din codul prezentat nu se vede ca poate fi plug-in, dar e usor sa injectezi repository-ul in biblioteca centrala (cea vendor-free si cu business value in ea).
Tangential cu “injectezi”, eu unul prefer injectarea manuala a dependintelor in biblioteca centrala, fara DiC, ci prin constructor. Avantajul e o documentare mai clara a business-ului; i.e. vezi direct din cod “pentru a construi conceptul A, trebuie sa construiesti mai intai conceptele B si C”.