Điều gì được coi là mã bên thứ ba?


15

Lấy cảm hứng từ câu hỏi này Sử dụng thư viện của bên thứ ba - luôn sử dụng trình bao bọc? Tôi muốn biết những gì mọi người thực sự coi là thư viện của bên thứ ba.

Ví dụ từ PHP:
Nếu tôi đang xây dựng một ứng dụng bằng khung Zend, tôi có nên coi các thư viện khung Zend là mã của bên thứ ba không?

Ví dụ từ C #:
Nếu tôi đang xây dựng một ứng dụng máy tính để bàn, tôi có nên coi tất cả các lớp .Net là mã của bên thứ ba không?

Ví dụ từ Java:
Tôi có nên coi tất cả các thư viện trong JDK là thư viện của bên thứ ba không?

Một số người nói rằng nếu một thư viện ổn định và sẽ không thay đổi thường xuyên thì người ta không cần phải bọc nó. Tuy nhiên tôi không thấy cách người ta kiểm tra một lớp phụ thuộc vào mã của bên thứ ba mà không gói nó.


8
Các cử tri xuống có thể giải thích tại sao?
Songo

Tôi đã nghe nói về phần mềm của bên thứ ba, nhưng không phải mã của bên thứ ba. Hầu hết các bên thứ ba không cung cấp cho bạn mã nguồn của họ.
Tulains Córdova

Câu trả lời:


18

Ví dụ của bạn là tất cả mã của bên thứ ba, nhưng bạn không nên viết các hàm bao cho chúng. Chúng là những dự án lớn, trưởng thành với các API ổn định và được lên kế hoạch tốt.

Sự cần thiết của trình bao bọc là cung cấp một lớp trừu tượng giữa mã của bạn và thư viện. Bạn chỉ cần sự trừu tượng này khi bạn phát hiện ra rằng một thư viện không cung cấp API tốt cho việc cụ thể bạn đang làm. Sau đó, bạn có thể tạo trình bao bọc để đơn giản hóa mã của riêng mình và che giấu sự thật rằng các lệnh gọi API rất khó xử.

Mã của bạn sẽ được kiểm tra nếu bạn sử dụng phép nội xạ phụ thuộc. Trong các thử nghiệm đơn vị của bạn, bạn có thể trao đổi phụ thuộc thư viện với một đối tượng giả, cho phép bạn tách mã của mình theo thử nghiệm.


+1 để giải thích khi bao bọc hoặc mặt tiền, nếu bạn muốn, có thể là cần thiết.
Joshua Drake

Cảm ơn câu trả lời, nhưng liên quan đến đoạn cuối cùng về kiểm thử đơn vị, bạn có thể xem câu hỏi này khi tôi đang cố gắng kiểm tra một lớp có sự phụ thuộc trực tiếp vào khung thư viện không?
Songo

@Songo: Chiến lược thử nghiệm của bạn nên là tạo ra một Zend_Mailgiả mà bạn truyền cho Loggerđối tượng của mình đang thử nghiệm. PHP không hỗ trợ gõ vịt? Nếu vậy, không nên tầm thường để tạo một đối tượng giả ...? Tôi thực sự không biết PHP, nhưng bạn có thể xem các ví dụ từ các thư viện chế nhạo PHP để xem nó thường được thực hiện như thế nào. Trong các ngôn ngữ không hỗ trợ gõ vịt, sau đó tôi nghĩ bạn sẽ cần thay đổi Zend_Mailgiao diện, sau đó tạo một trình bao bọc mỏng thực hiện giao diện và kế thừa từ Zend_Mailhoặc chỉ ủy thác tất cả các cuộc gọi của nó.
M. Dudley

@emddudley cũng có, nhưng tôi đang tìm một giải pháp tổng quát hơn cho vấn đề bằng các ngôn ngữ khác không hỗ trợ gõ vịt. Trên thực tế, giải pháp bọc của bạn Zend_Maillà suy nghĩ đầu tiên của tôi, nhưng như bạn có thể thấy trong bài viết gốc của mình trước khi chỉnh sửa, tôi đã sử dụng một giao diện và trình bao bọc thực hiện nó. Tuy nhiên, mục đích duy nhất của trình bao bọc để tồn tại là để tôi có thể giả định giao diện của nó. Điều đó có phổ biến trong các ngôn ngữ không hỗ trợ gõ vịt không? Xây dựng vô hạn không có ý nghĩa bao bọc?
Songo

@Songo: Tôi nghĩ đó là ngôn ngữ và thư viện cụ thể, và bạn phải làm bất cứ điều gì nền tảng của bạn hỗ trợ. Đôi khi bạn có thể bị mắc kẹt với các trình bao bọc bằng văn bản. Tiêm phụ thuộc và chế nhạo đối tượng là những phát triển gần đây (2004?), Vì vậy không phải tất cả các ngôn ngữ và thư viện đều hỗ trợ chúng rất tốt. "Giải pháp chung" mà bạn đang tìm kiếm chỉ là một suy nghĩ: làm thế nào bạn có thể kiến ​​trúc mã của mình để ghép lỏng và kiểm tra đơn vị hiệu quả?
M. Dudley

6

Mục tiêu của việc gói thư viện là phá vỡ sự phụ thuộc của mã của bạn vào thư viện đó để cho phép:

  • Kiểm tra đơn vị - Bạn phải có thể kiểm tra mã của mình. Nếu một thư viện không cho phép bạn chế nhạo các lớp hoặc buộc trả lời mà bạn cần cho bài kiểm tra của mình, thì bạn sẽ cần phải bọc thư viện đó. Đây là một vấn đề rõ ràng, và có lẽ không phải là trường hợp bạn đang tự hỏi về.
  • Thay đổi triển khai - Là tác giả mã, bạn cần hiểu các thay đổi có thể xảy ra theo cách của bạn và những thay đổi đó sẽ tốn bao nhiêu để chuẩn bị so với khả năng của chúng. Bạn có thể chuyển từ .NET sang JVM không? Điều đó thật khó khăn và khó xảy ra; tuy nhiên, bạn rất có thể thay đổi các công nghệ UI trong tương lai hoặc các công cụ XML.

Cô lập các thư viện và khung của bên thứ ba chỉ là một tập hợp con của sự thay đổi cô lập.


Điểm rất tốt về thử nghiệm đơn vị. Tôi không nói luôn luôn gói gọn để có thể đơn vị kiểm tra ứng dụng của bạn, nhưng đó là một chiến lược tốt để tách riêng các phụ thuộc khi cần thiết.
Sergio Acosta

2

Tôi sẽ không coi các thành viên của thư viện tiêu chuẩn là mã của bên thứ 3 - rốt cuộc họ là tiêu chuẩn và có thể được cho là hợp lý và có sẵn trên nền tảng bạn đang sử dụng.

Đối với một cái gì đó như Zend, tôi nghĩ rằng người ta sẽ không bao bọc nó - có lẽ bạn sẽ cần phải viết lại chương trình nếu bạn thực hiện trên một khung khác. Thành thật mà nói, tôi sẽ không bao bọc nhiều thứ không phải là một sự phụ thuộc cấu hình bên ngoài nghiêm trọng hoặc nếu tôi không thực sự có kế hoạch làm cho phần đó có thể hoán đổi được.


2

Tôi sẽ coi các thư viện được cung cấp bởi một ngôn ngữ lập trình cụ thể chỉ là một phần của ngôn ngữ.

Hơn, tôi sẽ xem xét bên thứ ba, tất cả các thư viện được cung cấp bởi bất kỳ thực thể nào khác như một phần mở rộng hoặc một công cụ riêng biệt từ chính ngôn ngữ lập trình.

Lấy ví dụ của bạn, tôi sẽ coi Zend là bên thứ ba. Tôi cũng sẽ xây dựng ứng dụng của mình theo cách mà logic kinh doanh cốt lõi của tôi sẽ không phụ thuộc vào Zend.

Wikipedia định nghĩa thành phần bên thứ ba là:

Trong lập trình máy tính, thành phần phần mềm của bên thứ ba là thành phần phần mềm có thể sử dụng lại được phát triển để được phân phối hoặc bán tự do bởi một thực thể không phải là nhà cung cấp ban đầu của nền tảng phát triển.


1

Theo nghĩa chặt chẽ nhất, mọi ví dụ bạn đưa ra là mã của bên thứ ba. Tuy nhiên, không phải tất cả các mã bên thứ ba nên được bọc. Tất cả các thư viện bên thứ ba nên được bọc. Các khung, theo định nghĩa, không thể được bọc bởi vì chúng trở thành một phần và phần của mã của bạn. Đó là lý do tại sao bạn sẽ bọc thư viện ghi nhật ký của mình, nhưng không phải khung .NET hoặc khung Zend. Bạn thực sự không thể tách mã của mình khỏi .NET - chúng được đan xen. Tất nhiên, các khung tốt sẽ có giao diện để lập trình chống lại, cho phép bạn bỏ qua vấn đề ở một mức độ nào đó.

Xem thêm: /programming/148747/what-is-the-difference-b between-a-framework-and-a-l Library

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.