认识达内从这里开始

任何一项编程开发技术的应用都是需要从多方面来进行考虑的，今天我们就通过案例分析来简单了解一下，组件化编程开发常见问题都有哪些。

通常来讲当我们使用一种新的技术方案解决现有问题的时候也会带来一些新的问题，组件化架构能带来多少收益主要取决于整个工程组件化的质量。那在组件化架构中我们如何去评估项目工程的组件化架构质量，我们需要关注哪些问题。对于软件架构来讲，重要的就是管理组件实体以及组件间的关系。所以对于组件化架构来讲主要是关注以下三个问题：

如何划分组件的粒度、组件职责边界在哪里?

组件间的依赖关系应该如何管理?

组件间应该使用哪种方式调用和通信?

1.组件拆分的粒度、组件职责边界在哪里?

某种程度上组件拆分粒度也是一种平衡的艺术，我们需要在效率和质量之间找到一种相对的平衡。组件拆分粒度太粗：导致组件间耦合紧密，并不能利用更好的复用/解耦/提高编译速度这些优势。组件拆分粒度太细：导致需要维护更多的组件代码仓库、功能变更可能涉及多个组件代码的修改/发布，这些都会带来额外的成本，同时组件过多也会导致组件依赖查找过程变的更复杂更慢。

组件的职责也会影响我们对于组件的拆分方式：每个组件的定位是什么，应该包含什么样的功能，是否可以被复用，添加某个功能的时候应该创建新组件还是添加到现有组件，当组件复杂到一定程度时是否需要拆分出新个组件。

在拆分组件前需要提前去思考这些问题。

2.组件间的依赖关系应该如何管理?

组件间的依赖方式主要分为直接强耦合依赖和间接松耦合依赖。强耦合依赖是对依赖的组件直接使用对应的API进行调用，这种调用方式优点是简单直接性能更好，缺点是一种完全耦合的调用方式。(基础组件通常使用这种方式)。松耦合依赖主要是通过通知、URLScheme、ObjCRuntime、服务接口、事件队列等通信方式进行间接依赖调用。虽然性能相对差一点，但这是一种相对耦合程度比较低并且灵活的依赖方式。(业务组件通常使用这种方式)

组件间的依赖关系很重要是因为在长期的项目开发演化过程中很容易形成一种复杂的网状依赖关系。虽然看似使用组件化的方式将模块拆分成不同的组件，但是组件间可能存在很多相互交叉的依赖耦合关系，很多组件都被其他组件直接依赖或隐式间接依赖。这样我们就背离了组件化架构更好的解耦、更好的复用、更快速的开发/编译/发布的初衷。

所以我们需要制定一套规范去约束和规范组件间的依赖关系：两个组件之间是否可以依赖，组件间依赖方向，选择强耦合依赖还是松耦合依赖。

3.组件间松耦合依赖关系应该使用哪种方式调用和通信?

松耦合依赖通常可以使用通知、URLScheme、ObjCRuntime、服务接口、事件队列等方式通信进行间接调用，但是使用哪种方式更好业界也有很多争论，并且每种方式都有一些优缺点。通常在项目中会根据不同的使用场景至少会选择2种通信方式。

耦合程度低的方式例如URLScheme，可以做到完全解耦相对比较灵活。但是无法利用编译时检查、无法传递复杂对象、调用方/被调用方都需要对参数做大量的正确性检查和对齐。同时可能无法检测对应的调用方法是否存在。

耦合程度高的方式例如服务接口，需要对服务接口方法进行强依赖，但是可以利用编译时检查、传递复杂对象、并且可以更好的支持Swift特性。

我们需要在解耦程度、容易使用、安全上找到一种合适的方式。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。