何時，爲什麼以及如何使用包裝？

Question

我正在談論第三方庫的包裝。直到最近，我試圖提供一個通用的包裝器，所以我可以根據需要輕鬆切換庫。然而，事實證明這幾乎是不可能的，因爲即使在處理基本概念方面，圖書館也可能有很大差異。

所以問題來了，爲什麼我們應該使用包裝。 （過去，我被有經驗的編程人員鼓勵爲第三方庫編寫包裝。）我得出以下結論：請告訴我他們是否有錯或者是否有任何補充。

• 如果該庫沒有在應用程序中廣泛使用（例如，只有一個或兩個類使用），請不要編寫包裝器，直接使用它。 （尤其是如果它是一個可移植的庫）
• 當你寫封裝器不認爲你可以做出一個適合所有封裝。寫一些適合於lib的優點的東西。
• ...但在某些情況下，您仍然可以將包裝器概括得足夠多，以便切換庫會更容易一些。 （例如：大多數圖形庫使用圖像和字體。）
• 當庫提供比您需要的更多功能時，包裝器非常有用。您可以將不需要的功能隱藏在包裝中。
• 對於C庫（如果您使用的是C++），您還可以編寫一個包裝來幫助您進行自動內存管理。

您認爲使用包裝的（dis）優點，以及它們應該如何正確使用？

Answer 1

我認爲你已經擊中了頭部，包裝只是爲了讓某些東西可能被換出是一個壞主意。經典的例子是一個數據庫，他實際上曾經不得不從SQL切換到Oracle（我知道人們有，但多久使用一次包裝真的有幫助？）。

根據我的經驗，只有將包含2+調用的第三方組件或api隱藏到一個調用中，這意味着某些調用代碼（基本上是facade pattern)或者包裝代碼並添加了值/類型轉換爲調用者（一個adapter pattern）。

所以包裝必須在這裏，現在提供一個造福於消費者，而不是一個潛在的未來利益（以系統編碼器），可能永遠不會被需要。

Answer 2

如果你想隔離測試。例如我的開發系統與我沒有任何關係客戶活動目錄擁有用戶名和角色。所以我有一個UserInfoWrapper接口有兩個實現：一個使用ActiveDirectory和一個用於開發的假用戶數據。

Answer 3

「在計算機科學中的所有問題都可以通過間接的另一個層面來解決」，由巴特勒·蘭普森

有參與創建一個抽象的包裝第三方庫的成本。你需要決定成本是否值得。對於例如在UI工具包或庫上創建包裝是非常困難的（或者至少涉及顯着的開發成本）。相反，爲第三方日誌記錄庫創建包裝相對容易。

包裝程序也可用於在第三方庫文件之上提供域特定和簡化的API。門面模式可能會有所幫助（正如Paul Hadfield上面提到的）。