Tag: 依赖反转

SOLID原则-第5部分

依赖倒置原则指出，较高级别的模块不应依赖于较低级别的模块，它们都应依赖于抽象。 换句话说，所有实体都应基于抽象接口，而不应基于具体类型 。 该原则还强调，抽象不应依赖细节。 细节应取决于抽象。 因此，这里的技术问题是什么是更高级别的模块？ 或我们可以定义为较低级别的模块？ 高级 模块是包含应用程序的策略决策和业务模型的任何模块。 这可以视为应用程序标识。 更高级别的模块主要由应用程序中的表示层使用。 低级模块是包含执行决策和业务策略所需的详细实现的模块。 依赖倒置原则有时被误认为是依赖注入。 虽然这些术语看起来彼此相似，但它们完全不同。 依赖注入是为对象提供实例属性或变量的过程。 但是，不提及依赖注入就很难谈论依赖倒置原理。 这是因为您需要依赖注入机制来实现依赖倒置。 假设我们要使用“ UserDefaults ”在应用程序中保留，读取和擦除一些用户编码的数据，并带有一些将实际实现逻辑分开的高级抽象。 到目前为止，我们将使用Swift语言作为实际示例的SOLID原理带到了旅程的尽头，之前的原理是关于接口隔离 对于完整的操场，您可以在github仓库中找到它。 请随时与我们联系。 我期待知道您的想法。 我也写过迅捷的associated-type请看一看。 鲍勃·戈德温（@bobgodwinx）| 推特 Bob Godwin（@bobgodwinx）的最新推文。 移动团队首席工程师@dunnhumby Germany GmbH。 @Apple的粉丝… twitter.com

如何在iOS中应用依赖反转

您在大学时代曾经遇到过有关依赖倒置原则的话题吗？ 在面向对象的编程中，该原理指的是解耦软件模块的一种特定形式（如Wiki所述：https：//en.wikipedia.org/wiki/Dependency_inversion_principle） 高级模块不应依赖于低级模块。 两者都应依赖抽象。 抽象不应依赖细节，而细节应依赖抽象。 在我大学期间，这个概念似乎真的很有价值，但是我从来没有实践过。 当我们将此原则付诸实践时，我们可以意识到它可以在开发项目结构方面起到多大的作用。 对于许多开发原则，去耦是设计代码中最重要的方面之一，而该原则解决了这一挑战。 但是我们如何在我们的iOS项目中应用这一原理？ 实际上，我们不需要从头开始创建遵循依赖关系反转的类。 实际上，Apple鼓励我们使用这种模式。 委派模式是整个iOS应用程序中最常用的模式之一。 如果您曾经使用过UIImagePickerController并实现了它的方法以符合标准，那么您已经遵循了依赖关系反转原理。 同样，当我们通读以下内容时： 高级模块不应依赖于低级模块。 两者都应依赖抽象。 高级模块是UIImagePickerController-该模块可以独立运行，并且具有功能框架（即抽象）。 但是其功能的使用尚不确定。 这是低级模块现在定义的时间（这是您的代码） 抽象不应依赖细节，而细节应依赖抽象。 还要注意这一点，当您在iOS中使用要求您遵守协议的类或模块时，需要您的类来实现其方法。 即，UITableViewDatasource，UItableViewDelegate，UIImagePickerController等。 即使苹果已经为我们提供了具有依赖关系反转就绪类的类，但是在我们公司的发展中仍有一段时间我们公司希望我们创建模块化的类，这些类可以在其他项目中重用。 （是的，为将来的项目节省时间和金钱。） 借助依赖关系反转的心态，我们可以重构一些旧项目，甚至可以从那里的可重用模块中提取出来。 就像您真正喜欢的“位置选择器”或“自定义相机控制器”一样。 您甚至可以制作符合特定标准或公司感觉的模块。