Khi nói về sự phụ thuộc , cả hai thuật ngữ đều có thể được sử dụng, đôi khi theo cách (nguy hiểm) có thể hoán đổi cho nhau. React là một framework hay một thư viện? Thế còn Bootstrap hoặc Lodash thì sao ? Rốt cuộc thì cả hai đều là “ gói ”, phải không?

Chắc chắn rồi, nhưng chúng chắc chắn không có tác động tương tự đối với ứng dụng của bạn.

thư viện

Thư viện ("bibliothèque" trong tiếng Pháp, nhưng hầu hết người Pháp nói "librairie" thực ra có nghĩa là "hiệu sách" trong tiếng Pháp, nhưng khớp với cách phát âm tiếng Anh của "library") là một tập hợp các chức năng cho các mục đích chung (như underscore.js ) hoặc những cái chuyên biệt (như moment.js ).

Bạn gọi các hàm thư viện bất cứ khi nào bạn cần, giống như bạn chọn các công cụ trong hộp công cụ. Chúng không yêu cầu bất kỳ thay đổi nào trong thiết kế phần mềm của bạn .

cuộc gọi độc quyền

Tuy nhiên, với tư cách là một phần phụ thuộc, họ yêu cầu bạn gọi API độc quyền của họ, do đó "khóa" mã của bạn với họ (hoặc thậm chí có thể là một phiên bản của họ), để lệnh gọi thư viện sẽ giống như sau:

Việc khóa như vậy sẽ tăng theo số lượng lệnh gọi bạn đang thực hiện: bạn càng gọi nhiều cho thư viện, mã của bạn càng phụ thuộc vào nó (hoặc vào một phiên bản của nó):

Điểm phụ thuộc duy nhất

Tuy nhiên, để hạn chế sự phụ thuộc như vậy, bạn có thể ẩn nó sau một trình bao bọc:

Một trình bao bọc như vậy thực sự có thể phục vụ nhiều mục đích. Ngoài việc giảm khóa thành một điểm duy nhất trong cơ sở mã của bạn, nó cho phép bạn hiển thị api của chính mình cho người gọi. Việc điều chỉnh thư viện như vậy sẽ chỉ làm nổi bật API phù hợp với ứng dụng của bạn, cũng như các loại I/O dành riêng cho ứng dụng của bạn, không dành cho thư viện.

Tuy nhiên, nói về triển khai, từng bước một, mã của bạn vẫn phụ thuộc vào mã của thư viện.

API kinh doanh

Hy vọng, như David J. Wheeler quá cố đã từng nói:

Tất cả các vấn đề trong khoa học máy tính có thể được giải quyết bằng một cấp độ gián tiếp khác .

Thật vậy, bạn có thể tránh sự phụ thuộc như vậy bằng cách thêm một giao diện :

• người gọi sẽ phụ thuộc vào khai báo API đó;
• bộ điều hợp sẽ phải triển khai nó (lưu ý rằng điều này cũng sẽ giúp các thư viện chế nhạo dễ dàng hơn khi thử nghiệm).

khung

Các khung ("quadriciels" trong tiếng Pháp chính thức, nhưng mọi người đều nói là "khung") thì khác, vì chúng cung cấp một loại dịch vụ khác: chúng đề nghị quản lý mọi thứ cho bạn, thay vì cho phép bạn nghĩ ra những việc cần làm.

Bàn giao quyền kiểm soát

Để làm như vậy, chúng triển khai xương sống ("khung") của ứng dụng và cho phép bạn điền vào chỗ trống. Nhưng những khoảng trống đó được để ở những vị trí xác định và có hình dạng xác định.

Đó có nghĩa là:

• ứng dụng bắt đầu với khuôn khổ : bạn phải bàn giao vô lăng.
• vì khung điều khiển ứng dụng, bạn không phải là người thực hiện cuộc gọi nữa: thay vào đó, bạn sẽ được khung gọi lại khi thích hợp.

hợp đồng

Tất nhiên, không có gì ngăn cản bạn gọi thủ công một số mã của riêng bạn, thư viện của bên thứ ba hoặc thậm chí một số API khung, nhưng bạn phải tự chịu rủi ro . Điều này có thể hoặc không thể làm việc như bạn mong đợi. Các khung có các quy tắc mà bạn phải tuân theo và nếu bạn vi phạm chúng, khung đó không thể chịu trách nhiệm cho bất kỳ lỗi nào.

Thông thường, một khung sẽ cho phép bạn viết các thành phần phù hợp với vùng chứa của chúng thông qua việc triển khai hợp đồng :

Khi đó, bộ chứa sẽ có thể xử lý mã của bạn dưới dạng một phần mềm tương thích với khung có thể quản lý vòng đời của nó và sẽ gọi lại cho bạn vào những thời điểm phù hợp để thực hiện một số loại thao tác này hay loại thao tác khác.

Như bạn có thể thấy, đây là một lựa chọn mang tính cấu trúc hơn nhiều mà các thư viện dành cho thiết kế ứng dụng của bạn: tất cả các thành phần của bạn trở nên cụ thể đối với khung đó. Sẽ không thể di động (tức là không được hiểu bởi một khung khác) cũng như không thể tương tác (tức là một thành phần Angular sẽ khó tương tác với một thành phần React).

Tuy nhiên, người ta có thể lập luận rằng mẫu bộ điều hợp có thể được sử dụng để hạn chế sự phụ thuộc vào khung, giống như chúng ta đã làm để hạn chế sự phụ thuộc vào thư viện:

Điều này có vẻ hữu ích… nếu hướng phụ thuộc giống nhau. Nhưng không phải vậy: các bộ điều hợp thư viện được sử dụng để có hình dạng theo yêu cầu của ứng dụng, trong khi ở đây, các bộ điều hợp thành phần chỉ có thể có hình dạng như những gì khung mong đợi. Do đó, thành phần ứng dụng được cho là “miễn phí” chỉ có thể bắt chước hợp đồng ban đầu (vòng đời, ngữ nghĩa, mức độ chi tiết).

Khi đó, bên trong các khung, các bộ điều hợp thành phần sẽ không cần thiết phải phân lớp.

thư viện khung

Các thư viện cũng có thể tuân theo các khuôn khổ. Thay vì cung cấp API, họ cung cấp các triển khai thành phần cho một khung nhất định.

Khi các khung trở nên phổ biến, một số thư viện khung đã có sẵn. Tuy nhiên, hầu hết trong số chúng là về các widget: ví dụ: các thành phần Thiết kế Vật liệu đã được chuyển từ Android sang Thành phần Web , Góc , Phản ứng , Vue và thậm chí cả các khung công tác iOS .

khung tiêu chuẩn

Bất kỳ ai cũng có thể tưởng tượng được chi phí khổng lồ của việc chuyển cùng một thư viện (và các phiên bản tiếp theo của nó) trên mỗi khung công tác đó.

IBM đã nghĩ ra một giải pháp cho vấn đề này : thay vì chuyển Hệ thống Thiết kế Carbon của họ trên từng khung được thổi phồng trong quá khứ, hiện tại và tương lai, họ đã đầu tư vào một cổng trên khung Thành phần Web tiêu chuẩn , có thể được sử dụng trong mọi ngữ cảnh.

Vì vậy, điều này không chỉ cho phép sử dụng các thành phần của chúng từ các khung:

Nhưng các thành phần tương tự cũng có thể được sử dụng từ một ứng dụng đơn giản:

Phần kết luận

Các khung và thư viện là các tùy chọn của bên thứ ba rất khác nhau:

• các khung cung cấp cho bạn bản thiết kế ứng dụng với các dịch vụ tích hợp nhưng thực thi các hợp đồng được xác định trước để gọi mã của bạn. Như vậy, chúng ngụ ý một sự phụ thuộc mạnh mẽ .
• các thư viện sẽ không giúp bạn thiết kế ứng dụng của mình mà chỉ có thể được gọi khi bạn cần chúng. Bạn có thể nghĩ ra một thiết kế hạn chế sự phụ thuộc vào chúng.