開放源代碼庫的Api /插件？

Question

無論何時我使用開源庫，例如。學說我總是最終編寫一個類（所謂的Facade）來使用Doctrine庫。

所以下次我想創建一個用戶我只需鍵入：

$fields = array('name' => 'peter', 'email' => 'peter@gmail.com'); 
Doctrine_Facade::create_entity($entity, $fields); 

然後它會創建與所提供的信息的實體。

所以我想，所有的編碼器都會創建自己的「外觀」。

我不知道它是如何與開源Facades下載和與開放源碼庫互動如何？這是罕見的原因，我還沒有看到任何這些。在我看到他們稱爲插件的一些框架中，例如。 twitter api或Facebook api的插件。

因此，無論何時您下載庫，您是否應該在網上搜索插件/外牆，還是嘗試編碼自己的代碼更好？我只是覺得每個人都不要重新發明車輪是件好事。

謝謝。

Answer 1

讓我們說它不只是關於工廠，讓我們說，你真的經常爲你使用的圖書館編寫Facades。有什麼意義？你爲什麼這樣做？問題是，你以特定的方式使用庫。如果你寫的門面是普遍的，每個人都傾向於寫這樣的東西，門面肯定是圖書館的一部分。所以它不是的原因以及你爲什麼要編寫它的原因是，你以一種非常特定的方式使用它，這是特定於你的應用程序庫的。所以你從庫的抽象過渡到應用程序的抽象。這可以從應用程序中刪除庫的大部分複雜性，但也會限制您使用庫的方式。所以，如果你明白了我的觀點，你可能會確信，以某種方式釋放每個Facade在圖書館的使用方面沒有意義。但是，有時候，當我們談論一個很有影響力的大型圖書館時，它與其他一些圖書館結合在一起，形成了可以廣泛使用的抽象概念，可能會發生新的圖書館的誕生。

Answer 2

一個正面的目的是（quoting）

• 提供一個統一的接口子系統中的一組接口。 Facade定義了一個更高級別的界面，使得子系統更易於使用。
• 使用更簡單的界面包裝複雜的子系統。

雖然上面可以說是適用於你的榜樣，它更像一個AbstractFactory感覺給我。您可能希望將其重命名爲EntityFactory而不包含Doctrine部分，因爲它在內部使用Doctrine的事實是一個實現細節。對於面向工廠的API的公衆來說，這並不重要。也許你想稍後從Doctrine改爲Propel，然後你只需要改變類內的代碼，而不是API。您可能也有興趣Gateway pattern。

但回答你的問題，這是否是一種常見的方法：是的，我認爲是這樣。抽象使代碼更容易理解並更易於維護。但是由於門面/網關的API（無論適用）通常取決於應用程序的功能，因此很少可以重複使用，所以我懷疑你會在網上找到現成的門面/網關。