处理第三方API时，正确的系统devise是什么？

Joubert的这篇博文只是睁开了眼睛。 我已经处理了很多Java和其他语言的devise模式。 但Objective-C是一种相当独特的语言。

假设我们在一个项目中使用Dropbox或Facebook等第三方API。 到目前为止，我一直在做的就是把所有与第三方API有关的东西整合到一个单独的类中。 所以我可以从我的视图控制器中的任何地方访问这个类。 我可以举个例子： [[DropboxModel sharedInstance] uploadFile:aFile]

然而正如博客文章所指出的那样，这样做效率不高，导致意大利面代码和unit testing不合格。 那么devise系统的最好方法是什么，以便模块化和易于使用？

Answer 1

我会质疑单身人士会导致意大利面代码，效率低下。 然而，unit testing问题是合法的，单例模式确实降低了模块性，因为它们实际上只是一个奇特的全局variables。

我喜欢Joubert从应用程序代理（它本身就是一个单身人士，ahem）将单例实例注入控制器的想法。 我认为同样的方法会适合你。

我通常在这些情况下做的，我可能想在unit testing中使用不同的存根对象，定义一个协议来表示API，并使我的“真实”的API对象和我的存根API对象一致。 我使用unit testing中的存根和应用程序中的实际对象。

Answer 2

并不是说这真的解决了与单例相关的任何体系结构问题，但是为了可读性和可打字性，您总是可以在DropboxModel头文件中定义一个macros，例如：

 #define DBM [DropboxModel sharedInstance] <...> [DBM uploadFile:aFile]; 

Answer 3

我通常会创build一个抽象层。 这将简单的接口包装到你使用的库的调用中，同时给你一个机会介绍你需要的任何状态（如variables）。

那么你就可以只暴露你需要和使用的东西，并添加你自己的状态，检查，并从一个地方方便地处理图书馆的所有问题。 “问题”可能由于以下几个原因而被引入 – 它可能是线程，资源，状态或不同版本之间的不希望的行为变化。

大多数图书馆并不意味着只能通过一个单身人士使用。 在这种情况下，最好（主观）像通常那样创build接口 – 当然，要注意抽象层背后的约束。 从这个意义上讲，您只需创build基于大小/任务/目的/function划分的基于对象的接口 – 就像您在编写自己的类时通常所做的一样。

如果你不需要遍布整个图书馆的地方，那么我认为把你所需要的最小化依赖关系（在大型项目中越来越重要）也是很好的做法。

如果你在各地使用库，那么你也可能更喜欢使用没有抽象层的调用。