包装SDK的设计模式

Question

我们公司购买了可用于Android应用的SDK。 SDK是用java编写的，非常大。

我必须为此SDK创建一个包装器，以便我们的合作伙伴不需要直接使用SDK，而是调用我们的wapper函数。

我想知道做这样的工作的最佳设计模式是什么？我一直在研究代理设计模式，但不确定这是否正确。

非常感谢任何建议，

Answer 1

想到的是Facade pattern。

来自维基百科的描述：

  

外观是一个为更大的界面提供简化界面的对象   代码体，例如类库。

外观模式是GoF book中描述的原始设计模式之一。那里的描述如下：

  

为子系统中的一组接口提供统一接口。   Facade定义了构成子系统的更高级别的接口   更容易使用。

似乎完全符合您的使用案例。

Answer 2

这听起来像是立面图案的经典案例。您希望为合作伙伴设计一个API，以捕获您的高级用例。该实施将委托购买此SDK，但不允许其实施细节传播到您的合作伙伴代码。

http://en.wikipedia.org/wiki/Facade_pattern

代理模式与此问题的相关性较低。代理往往是针对基础结构要求的一对一映射到包装的API。经典的例子是远程方法调用。

http://en.wikipedia.org/wiki/Proxy_pattern

Answer 3

Facade模式听起来最合适。

但是，选择最佳设计模式并不能保证成功。你是否会成功真的取决于你试图＆＃34;包装＆＃34;的SDK的性质，以及你真正试图通过包装它实现的目标。

例如，在过去的项目中，我犯了一个错误，即使用类似于Facade的包装器来抽象两个不同的三层存储API。我希望能够自由切换三重存储实现。这是个坏主意。我基本上最终镜像了Facade中的大部分API功能。这是一项重大的实施工作，最终结果并不简单。事后来看，这根本不值得。

总结：

• 如果您可以使您的外观API小而简单，这是一个好主意。 （理想的外观是简单地隐藏了一堆您不希望客户使用的复杂性或可配置性。）

• 如果您的外观庞大而复杂，并且/或者需要复杂的＆＃34;映射＆＃34;对于你正在包装的实际API，你可能需要编写很多代码，并且最终会得到一些客观上比你开始时更糟糕的东西。

Answer 4

我不认为可以在不确切知道合作伙伴将如何使用您的包装器的情况下回答这个问题。设计一个适合他们的API，然后将调用委托给相应的（系列）SDK调用。

如果你愿意，你可以称之为门面，但我认为你的任务更大。我说它是分层架构中的一个新层。在该图层中，您可以使用您认为合适的所有图案。