vendor lock-in - in final este doar a highly leaky abstraction avand in vedere ca toate exemplele au in spate cate un anume pattern si sunt dependente de context. Numarul de exceptii este atat de mare incat expresia in sine este vaporware.
Vendor lock-in il recunosti atunci cand o mare parte din codul specific business-ului e impletit (intertwined, a mai scris @Sapioit asta pe aici) cu apeluri la alte coduri straine asupra carora nu ai control (vendor code). Vendor lock-in e faptul ca nu poti schimba un vendor cu un altul care rezolva aceeasi clasa de probleme.
A avea control asupra unui cod = a putea modifica functionalitatea fara a renunta la beneficiile oferite de upstream (de exemplu updates).
legacy code e cod vechi, pe care vrei sa il elimini.
Iar acele patterns sunt unele dintre cele mai simple metode de a izola vendor code de codul tau, astfel incat sa il poti schimba atunci cand, cu timpul, va deveni legacy code.
Nu doar vendor code poate deveni legacy code, ci si codul tau. Uneori chiar si in interiorul propriei biblioteci poti trage cate un anticorruption layer. [1]
Ca la multe pattern-uri, diferenta dintre anticorruption layer si pattern-urile listate de tine e intentia. De exemplu, Delegate, Adapter, Facade si Factory, toate ascund o “alta implementare” din spate. La fel si anticorruption layer. Intentia lor insa este diferita.
[1] de exemplu, o forma foarte cruda de anticorruption layer e atunci cand intre doua subsisteme nu pasezi obiecte, ci raw data types, si “de partea cealalta” reconstruiesti obiecte pentru aceleasi entitati din business, insa dintr-o alta perspectiva. Este un anticorruption layer deoarece impiedica eventuale obiecte corupte in a corupe subsistemul receptor.
Era vorba de legacy code deja existent si interoperarea cu el pentru asta este folosit acel pattern. Felul cum pui problema intra in categoria de making assumptions sau/si over-engineering.
Deci daca folosesc promises sau/si async/await codul meu este locked-in to a vendor (the transpiler) conform definitiei.
Ideea este ca oricat ai incerca, nu poti elimina vendor lock-in-ul. Dar il poti limita. Si cat de mult il poti limita fara a iti dauna (atat pe termen scurt, cat si pe termen lung) este telul acestei discutii.
Am petrecut sarbatori linistite, si vad ca pe aici au fost discutii faine pe care le-am pierdut.
Nici eu nu cred va trebuie sa ne lasam la mana vendor lock-in, din motive economice in primul rand. Trebuie sa putem reduce costurile cu usurinta, nu chinuindu-ne solutia deja scrisa si functionala. Vin cu un exemplu din zona devops, inceputul discutiei de aici https://news.ycombinator.com/item?id=10794951 dezbate ceva gata facut (aws) dar scump vs ceva bare-bones dar ieftin. Diferentele sunt f mari, si un sysadmin e oricum necesar. Ar fi o mare greseala sa alegem aws.
Nu prea vad legatura cu avoiding vendor lock in, in timp ce citesti thread-ul, la un mom. se pune problema ca nu exista destule tutoriale pt. AWS apoi se revine la arg. ca toata lumea ar trebui sa citeasca documentatia i.e. their API in sensul ca AWS a devenit aproape un ‘limbaj’ necesar, macar la nivel minimal pt. un dev.
Deci deja avem un contra-argument puternic unde un vendor lock in devine the norm.
ceva bare-bones dar ieftin
Sunt multe horror stories cu bare-bones acel ieftin te poate costa in final mult mai mult, la fel cum rezulta si din comentariile pe HN → depinde de context.
