Swift Networking API：单例，全局或依赖注入？ [预习]
在本集中，我们将按照“加载提要用例”的要求开始实现RemoteFeedLoader （API）模块。
- 如何测试驱动API层实现
- 模块化设计
- 单例 ：何时何地，更好的替代方案，重构步骤逐步消除由单例产生的紧密耦合
- 控制依赖项 ：查找全局共享实例（隐式）与注入依赖项（显式），依赖项注入
我们有三个主要指南，用于设计和实现RemoteFeedLoader 。 用例中列出的步骤，上一集中定义的功能接口以及测试驱动的开发。
即使RemoteFeedLoader将是实现，我们也不会从遵循协议开始，因为它会要求我们考虑太多。 相反，我们可以通过测试驱动RemoteFeedLoader实现来采取更小（更安全）的步骤。 协议目前只是一个准则（功能接口的一部分），因此我们可以在最后遵循它。
我们继续演示RemoteFeedLoader的合作者RemoteFeedLoader的进化设计。 我们展示了这样的协作者如何可以从具体的单例开始，如何遵循由单元测试支持的详细过程，以确保当我们重构为更加模块化（基于协议）的解决方案时系统的行为不会改变。
HTTP客户端通常被实现为单例，只是因为定位共享实例可能更“方便”。 但是，我们认为，这种方法可能会被视为反模式，因为它会在模块之间引入紧密的耦合。 在我们的例子中， HTTPClient没有理由成为一个单例，因此能够与协作者通信的更合适的解决方案是使用依赖项注入。 然后，我们可以将定位协作者并将其注入到作曲者模块（例如Main）的责任，因此我们可以只专注于在其他组件之间传递消息。
加入Essential Developer Academy并观看整集！
在GitHub上跟踪项目的进度。
现在订阅我们的Youtube频道， 每周收看免费的新剧集。
最初在 www.essentialdeveloper.com上 发布 。
如果您喜欢本文，请访问我们的网站https://essentialdeveloper.com，并获得更多类似的深度定制内容。
在以下位置关注我们：YouTube•Twitter•Facebook•GitHub