Mówiąc o zależnościach , można używać obu terminów, czasami w (niebezpieczny) sposób zamiennie. Czy React to framework czy biblioteka? A co z Bootstrapem lub Lodashem ? W końcu oba są „ pakietami ”, prawda?

Jasne, ale zdecydowanie nie mają takiego samego wpływu na Twoją aplikację.

Biblioteki

Biblioteka („bibliothèque” po francusku, ale większość Francuzów mówi „librairie”, co w rzeczywistości oznacza „księgarnię” po francusku, ale pasuje do angielskiej wymowy słowa „biblioteka”) to zestaw funkcji do ogólnych celów (takich jak underscore.js ) lub specjalistyczne (jak moment.js ).

Wywołujesz funkcje biblioteczne, kiedy ich potrzebujesz, tak jakbyś wybierał narzędzia z przybornika. Nie wymagają żadnych zmian w projekcie oprogramowania .

Połączenia autorskie

Jednak jako zależność wymagają wywołania ich zastrzeżonego API, a tym samym „zablokowania” w nich kodu (lub nawet ich wersji ), tak aby wywołanie biblioteki wyglądało raczej tak:

Takie blokowanie będzie rosło wraz z liczbą wywołań, które wydajesz: im częściej wywołujesz bibliotekę, tym bardziej Twój kod jest od niej zależny (lub od jej wersji):

Pojedynczy punkt zależności

Aby jednak ograniczyć taką zależność, możesz ukryć ją za opakowaniem:

Takie opakowanie może tak naprawdę służyć więcej niż jednemu celowi. Poza ograniczeniem blokowania do pojedynczego punktu w bazie kodu, pozwala na udostępnienie własnego interfejsu API dzwoniącym. Taka adaptacja biblioteki będzie zawierała tylko interfejs API, który ma sens dla Twojej aplikacji, a także typy we/wy, które nie są specyficzne dla Twojej aplikacji ani biblioteki.

Jednak mówiąc o implementacji, krok po kroku, twój kod jest nadal zależny od biblioteki.

Biznesowe API

Miejmy nadzieję, że jak mawiał nieżyjący już David J. Wheeler:

Wszystkie problemy w informatyce można rozwiązać na innym poziomie pośrednim .

Rzeczywiście, możesz uniknąć takiej zależności, dodając interfejs :

• wywołujący będą zależni od tej deklaracji API;
• adapter będzie musiał go zaimplementować (zauważ, że ułatwiłoby to również wyśmiewanie bibliotek podczas testowania).

Ramy

Frameworki („quadriciels” w oficjalnym języku francuskim, ale wszyscy mówią „framework”) są inne, ponieważ zapewniają inny rodzaj usług: oferują zarządzanie rzeczami za ciebie, zamiast pozwalać ci wymyślać, co robić.

Przekazanie kontroli

Aby to zrobić, implementują szkielet („ramkę”) aplikacji i pozwalają wypełnić puste pola. Ale te puste miejsca są pozostawione w określonych miejscach i mają określone kształty.

Oznacza to, że:

• aplikacja zaczyna się od ramy : musisz oddać kierownicę.
• ponieważ platforma steruje aplikacją, nie jesteś już osobą, która wykonuje połączenia: zamiast tego zostaniesz oddzwoniony przez platformę, gdy będzie to konieczne.

Kontrakty

Oczywiście nic nie stoi na przeszkodzie, aby ręcznie wywołać własny kod, bibliotekę innej firmy lub nawet jakiś framework API, ale na własne ryzyko . To może, ale nie musi działać zgodnie z oczekiwaniami. Ramy mają zasady , których powinieneś przestrzegać, a jeśli je złamiesz, ramy nie mogą być pociągnięte do odpowiedzialności za jakąkolwiek awarię.

Zazwyczaj ramy pozwalają pisać komponenty , które będą pasować do ich pojemników poprzez wdrożenie umowy :

Kontener będzie wtedy w stanie obsłużyć Twój kod jako element oprogramowania zgodny z platformą, którego cyklem życia można zarządzać, i oddzwoni do Ciebie w momentach odpowiednich do wykonania jakiejś operacji.

Jak widać, jest to o wiele bardziej strukturalny wybór niż biblioteki dla twojego projektu aplikacji: wszystkie twoje komponenty stają się specyficzne dla tego frameworka. Nie będzie przenośny (tj. niezrozumiały dla innego frameworka) ani interoperacyjny (tzn. komponent Angular prawie nie będzie współdziałał z komponentem React).

Można jednak argumentować, że wzorca adaptera można użyć do ograniczenia zależności od frameworka, tak jak zrobiliśmy to, aby ograniczyć zależność od bibliotek:

Może to wyglądać równie dobrze… gdyby kierunek zależności był taki sam. Ale tak nie jest: adaptery bibliotek przybierały kształt wymagany przez aplikację, podczas gdy tutaj adaptery komponentów mogą przyjmować tylko kształt oczekiwany przez framework. W rezultacie rzekomo „darmowy” komponent aplikacji może jedynie naśladować pierwotną umowę (cykl życia, semantyka, szczegółowość).

Wewnątrz frameworków adaptery komponentów byłyby wtedy niepotrzebnymi warstwami.

Biblioteki ramowe

Biblioteki mogą również być zgodne z ramami. Zamiast dostarczać API, dostarczają implementacje komponentów dla danego frameworka.

Gdy frameworki stały się popularne, udostępniono wiele bibliotek frameworków. Jednak większość z nich dotyczy widżetów: na przykład komponenty Material Design zostały przeniesione z Androida do Web Components , Angular , React , Vue , a nawet frameworków iOS .

Ramy standardowe

Każdy może sobie wyobrazić ogromny koszt przeniesienia tej samej biblioteki (i jej kolejnych wersji) na każdy z tych frameworków.

Firma IBM opracowała rozwiązanie tego problemu : zamiast przenosić Carbon Design System na każdą z przeszłych, obecnych i przyszłych platform, zainwestowała w port na standardową platformę Web Component , której można używać w dowolnym kontekście.

Tak więc nie tylko pozwala to na wykorzystanie ich komponentów z frameworków:

Ale te same komponenty mogą być również używane ze zwykłej aplikacji:

Wniosek

Frameworki i biblioteki to bardzo różne opcje innych firm:

• Frameworks zapewniają plany aplikacji z wbudowanymi usługami, ale wymuszają predefiniowane kontrakty w celu wywołania twojego kodu. Jako takie implikują silną zależność .
• Biblioteki nie pomogą ci zaprojektować aplikacji, ale można je wywoływać tylko wtedy, gdy ich potrzebujesz. Możesz opracować projekt, który ograniczy do nich zależność.