椰子足在我们的发展中实际上做了什么
作为iOS的项目工程师，我们都知道cocoapods，著名的工具可以帮助我们在项目中进行依赖注入…。
首先，感谢可可豆荚的贡献者，感谢他们的分享。所以直到现在，我才意识到如果您在Web开发上花费更多的时间，Ruby是很棒的编程语言，您会喜欢Web框架-Ruby on Rails开发您的网站。您可以使用Ruby进行自动部署，也可以使用Ruby进行项目自动测试……但是今天，我的重点是cocoapods。
为什么在我们的iOS项目中进行依赖注入？
在软件工程中， 依赖项注入是一种技术，通过该技术一个对象可以提供另一个对象的依赖项。 依赖项是可以使用的对象（服务）。 注入是将依赖项传递给将使用它的依赖对象（客户端）。 服务已成为客户端状态的一部分。[1]将服务传递给客户端，而不是允许客户端构建或找到服务，是该模式的基本要求。
由于它的优势，因此我们在开发中总是使用依赖注入。
- 依赖注入使客户端可以灵活配置。 只有客户的行为是固定的。 客户端可以执行任何支持客户端期望的内部接口的操作。
- 依赖性注入可用于将系统的配置详细信息外部化为配置文件，从而无需重新编译即可重新配置系统。 可以针对需要组件的不同实现的不同情况编写单独的配置。 这包括但不限于测试。
- 由于依赖项注入不需要任何代码行为更改，因此可以将其作为重构应用于遗留代码。 结果是客户端变得更加独立，并且可以使用存根或模拟其他未测试对象的模拟对象来进行单独的单元测试。 当使用依赖注入时，这种易于测试通常是第一个注意到的好处。
- 依赖注入使客户可以删除其需要使用的具体实现的所有知识。 这有助于使客户免受设计变更和缺陷的影响。 它促进可重用性，可测试性和可维护性。[22]
- 减少应用程序对象中的样板代码，因为初始化或设置依赖项的所有工作均由提供程序组件处理。[22]
- 依赖注入允许并发或独立开发。 两名开发人员可以独立开发彼此使用的类，而只需要知道类将通过其进行通信的接口即可。 插件通常是由第三方商店开发的，它们甚至从未与创建使用插件的产品的开发人员交谈。
- 依赖注入减少了类与其依赖之间的耦合。
依赖注入的类型：
1，构造注射
类NSPersistenceStore：NSObject {
init（persistenceStoreCoordinator root：NSPersistenceStoreCoordinator ?,
configurationName名称：字符串？，
网址url：NSURL ?,
选项：[NSObject：AnyObject]？）
varsistenceanceStoreCoordinator：NSPersistenceStoreCoordinator吗？ {得到}
}
注意： 它确保依赖项始终存在于对象的生命周期中，并且它们在运行时不会更改，这使它更安全……。
2，接口注入
扩展UIViewController {
弱公共var transitionDelegate：UIViewControllerTransitionDelegate吗？
3，方法注入
公共协议NSCoding {
公共基金编码器WithCoder（aDecoder：NSCoder）
}
use：dependency可以随方法的每个方法或其时间的不同而变化，因此无需在方法范围之外存储对此依赖关系的引用。
我知道您的Mac上有一个可以使用的工具。
注射二，应用程序
注入将使用AppleScript与Xcode通信以确定当前文件和项目，然后将代码插入到… johnholdsworth.com
现在重点来了…。
为什么选择Cocoapods？
众所周知，CocoaPods是Swift和Objective-C Cocoa项目的依赖项管理器。 它拥有超过3.7万个库，并在超过250万个应用程序中使用。 CocoaPods可以帮助您优雅地扩展项目。
简而言之，您只需配置Podfile，然后执行命令行顺序，它就会自动完成…..
迦太基？
迦太基旨在成为向Cocoa应用程序添加框架的最简单方法。
基本工作流程如下所示：
- 创建一个Cartfile，列出要在项目中使用的框架。
- 运行Carthage，它将获取并构建您列出的每个框架。
- 将生成的
.framework二进制文件拖到应用程序的Xcode项目中。
迦太基构建您的依赖关系并为您提供二进制框架，但您保留对项目结构和设置的完全控制。 迦太基不会自动修改您的项目文件或构建设置。
迦太基和Co足类动物之间的差异
CocoaPods是Cocoa的长期依赖项管理器。 那么为什么要创建迦太基呢？
首先，CocoaPods（默认情况下）自动为您的应用程序和所有依赖项创建和更新Xcode工作区。 迦太基使用xcodebuild构建框架二进制文件，但有责任将它们集成给用户。 CocoaPods的方法更易于使用，而Carthage的方法则灵活且无干扰。
相比之下，迦太基已被创建为分散的依赖性管理器。 没有集中的项目清单，可以减少维护工作并避免任何集中的故障点。 但是，项目发现更加困难-用户必须诉诸GitHub的趋势页面或类似页面。
CocoaPods项目还必须具有所谓的podspec文件，该文件包含有关项目的元数据并指定应如何构建。 迦太基使用xcodebuild来构建依赖关系，而不是将它们集成到单个工作空间中，它没有类似的规范文件，但是您的依赖关系必须包含描述如何构建产品的自己的Xcode项目。
最终，我们创建了迦太基，是因为我们想要最简单的工具-一个依赖管理器，可以在不承担Xcode职责，无需为框架作者创建额外工作的情况下完成工作。 CocoaPods提供了Carthage永远不会拥有的许多令人惊叹的功能，但以增加复杂性为代价。
基于Cocoapods的自述文件，我们了解CocoaPods的目标
…通过创建更加集中的生态系统来提高第三方开源库的可发现性和参与度。
因此，大多数时候我们总是使用CocoaPods。
直到知道我发现有个很棒的博客来讨论这个话题，所以我停下来再次写它，链接如下。
https://www.objc.io/issues/6-build-tools/cocoapods-under-the-hood/
太酷了，感谢大家的阅读……如果您喜欢它，请拍手……。