Bağımlılıklar hakkında konuşurken , her iki terim de bazen (tehlikeli) birbirinin yerine kullanılabilir şekilde kullanılabilir. React bir çerçeve mi yoksa bir kütüphane mi ? Bootstrap veya Lodash ne olacak ? Sonuçta ikisi de “ paket ”, değil mi?

Elbette, ancak uygulamanız üzerinde kesinlikle aynı etkiye sahip değiller.

kütüphaneler

Bir kitaplık (Fransızca'da "bibliothèque", ancak çoğu Fransız "librairie" der, bu aslında Fransızca'da "kitabevi" anlamına gelir, ancak "library"nin İngilizce telaffuzuyla eşleşir) genel amaçlar için bir dizi işlevdir (underscore.js gibi ) . veya özel olanlar ( moment.js gibi ).

Bir araç kutusundan araçları seçer gibi, ihtiyaç duyduğunuzda kitaplık işlevlerini çağırırsınız. Yazılım tasarımınızda herhangi bir değişiklik gerektirmezler .

özel aramalar

Bununla birlikte, bir bağımlılık olarak, kendi özel API'lerini çağırmanızı, böylece kodunuzu onlarla (veya muhtemelen bir sürümünü ) "kilitlemenizi" gerektirirler, böylece bir kitaplık çağrısı şöyle görünmelidir:

Bu tür bir kilitleme, yaptığınız aramaların sayısıyla birlikte artacaktır: kitaplığı ne kadar çok ararsanız, kodunuz ona (veya onun bir sürümüne) o kadar bağımlı hale gelir:

Tek bağımlılık noktası

Bununla birlikte, böyle bir bağımlılığı sınırlamak için, onu bir sarmalayıcının arkasına gizleyebilirsiniz:

Böyle bir ambalaj kağıdı aslında birden fazla amaca hizmet edebilir. Kilitlemeyi kod tabanınızda tek bir noktaya indirmenin yanı sıra, kendi api'nizi arayanlara göstermenize olanak tanır. Kitaplığın bu şekilde uyarlanması, yalnızca uygulamanız için anlamlı olan API'yi ve uygulamanıza veya kitaplığa özgü olmayan G/Ç türlerini içerecektir.

Bununla birlikte, adım adım uygulama konuşursak, kodunuz hala kitaplığınkine bağımlıdır.

İş API'sı

Umarım merhum David J. Wheeler'ın dediği gibi:

Bilgisayar bilimindeki tüm problemler başka bir dolaylı düzeyle çözülebilir .

Aslında, bir arayüz ekleyerek bu tür bir bağımlılıktan kaçınabilirsiniz :

• arayanlar bu API bildirimine bağlı olacaktır;
• bağdaştırıcının bunu uygulaması gerekecektir (bunun, test sırasında kitaplıklarla alay etmeyi de kolaylaştıracağını unutmayın).

çerçeveler

Çerçeveler (resmi Fransızca'da "dörtlü", ancak herkes "çerçeve" der), farklı türde bir hizmet sundukları için farklıdırlar: ne yapacağınızı tasarlamanıza izin vermek yerine işleri sizin için yönetmeyi teklif ederler.

Kontrolü devretmek

Bunu yapmak için, bir uygulamanın omurgasını ("çerçeve") uygularlar ve boşlukları doldurmanıza izin verirler. Ancak bu boşluklar tanımlanmış yerlerde bırakılmıştır ve tanımlanmış şekillere sahiptir.

Bu şu demek oluyor:

• uygulama çerçeve ile başlar : direksiyon simidini teslim etmeniz gerekir.
• çerçeve uygulamayı yönlendirdiğinden, artık arama yapan siz değilsiniz: bunun yerine, uygun olduğunda çerçeve tarafından geri aranacaksınız .

Sözleşmeler

Elbette hiçbir şey kendi kodlarınızı, üçüncü taraf bir kitaplığı veya hatta bazı çerçeve API'lerini manuel olarak çağırmanıza engel olmaz, ancak risk size aittir . Bu, beklediğiniz gibi çalışabilir veya çalışmayabilir. Çerçevelerin uymanız gereken kuralları vardır ve bunları ihlal etmeniz durumunda çerçeve herhangi bir başarısızlıktan sorumlu tutulamaz.

Tipik olarak bir çerçeve, bir sözleşmenin uygulanması yoluyla kaplarına sığacak bileşenleri yazmanıza izin verir :

Konteyner daha sonra kodunuzu, yaşam döngüsü yönetilebilen çerçeve uyumlu bir yazılım parçası olarak işleyebilecek ve bir tür işlemi gerçekleştirmek için ilgili zamanlarda sizi geri arayacak.

Gördüğünüz gibi, bu, uygulama tasarımınız için kitaplıklardan çok daha yapısal bir seçimdir: tüm bileşenleriniz o çerçeveye özel hale gelir. Taşınabilir (yani başka bir çerçeve tarafından anlaşılmaz) veya birlikte çalışamaz (yani bir Angular bileşeni, bir React bileşeniyle neredeyse hiç etkileşime girmez).

Bununla birlikte, bağdaştırıcı modelinin, tıpkı kitaplıklara bağımlılığı sınırlamak için yaptığımız gibi, çerçeve bağımlılığını sınırlamak için kullanılabileceği iddia edilebilir:

Bağımlılık yönü aynıysa, bu yararlı görünebilir. Ancak öyle değil: kitaplık bağdaştırıcıları, uygulamanın gerektirdiği şekli alırken, burada bileşen bağdaştırıcıları yalnızca çerçevenin beklediği şekli alabilir. Sonuç olarak, sözde "ücretsiz" uygulama bileşeni yalnızca ilk sözleşmeyi taklit edebilir (yaşam döngüsü, anlamsal, ayrıntı düzeyi).

Çerçevelerin içinde, bileşen bağdaştırıcıları o zaman gereksiz katmanlama olacaktır.

Çerçeve kitaplıkları

Kütüphaneler ayrıca çerçevelere de uyum sağlayabilir. Bir API sağlamak yerine, belirli bir çerçeve için bileşen uygulamaları sağlarlar.

Çerçeveler popüler hale geldikçe, bir dizi çerçeve kitaplığı kullanılabilir hale geldi. Yine de çoğu widget'larla ilgilidir: örneğin, Materyal Tasarımı bileşenleri Android'den Web Components , Angular , React , Vue ve hatta iOS çerçevelerine taşınmıştır .

standart çerçeveler

Aynı kitaplığı (ve sonraki sürümlerini) bu çerçevelerin her birine taşımanın muazzam maliyetini herkes tahmin edebilir.

IBM bu konuda bir çözüm geliştirdi : Carbon Design System'i geçmiş, şimdiki ve gelecekteki abartılmış çerçevelerin her birine taşımak yerine , standart Web Bileşeni çerçevesinde herhangi bir bağlamda kullanılabilen bir bağlantı noktasına yatırım yaptılar.

Dolayısıyla, bileşenlerinin çerçevelerden kullanılmasına izin veren sadece bu değil:

Ancak aynı bileşenler düz bir uygulamadan da kullanılabilir:

Çözüm

Çerçeveler ve kitaplıklar çok farklı üçüncü taraf seçenekleridir:

• çerçeveler size yerleşik hizmetlere sahip uygulama planları sağlar, ancak kodunuzu çağırmak için önceden tanımlanmış sözleşmeleri zorunlu kılar. Bu nedenle, güçlü bir bağımlılık anlamına gelirler .
• kitaplıklar, uygulamanızı tasarlamanıza yardımcı olmaz, ancak yalnızca ihtiyaç duyduğunuzda çağrılabilir. Onlara bağımlılığı sınırlayan bir tasarım tasarlayabilirsiniz.