开放源代码库的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（无论适用）通常取决于应用程序的功能，因此很少可以重复使用，所以我怀疑你会在网上找到现成的门面/网关。