一 设计模式
1 协议，抽象类，具体类和范畴
通常，用圆角矩形表示类实体，在上部用粗体标出名字，下步是操作的名字。如果你看本书的电子版，你会看到协议的标题栏的背景为粉色，而其他类实体的标题栏背景为浅蓝色。抽象的名字用斜体表示。如图，各种类实体例子
左边具有抽象操作的协议；中间具有抽象操作的抽象类，右边为具体类。带有具体操作、具体属性和实例变量。
业务组件化或者叫模块化，在移动端应用架构中的一种主流方式之一，现在的iOS相关的框架Bifrost都是移动团队多年来的沉淀，对架构的设计的实践。也是让我们多实践和思考分析。补充：Bifrost也叫雷神里的彩虹桥
业务模块——组件化
以前传统的app强调分层。系统划分为基础层，网络层，UI层等等。现在分层已经做不到处理一些复杂的系统了，随着系统变得越来越复杂，容易造成App 内各子系统之间耦合严重, 边界越来越模糊，经常发生你中有我我中有你的情况。这对代码质量，功能扩展，以及开发效率都会造成很大的影响。此时，一般会将各个子系统划分独立模块，这时候架构逻辑会清楚很多，通过技术手段，消除中介者对业务模块依赖，即形成了业务模块化架构设计，如图下：
过业务模块化架构，一般可以达到明确模块职责及边界，提升代码质量，减少复杂依赖，优化编译速度，提升开发效率等效果。很多文章都有相关的知识点，就不细说了
业务常见的模块化的方案
业务模块化设计通过对各业务模块的解耦改造，避免循环双向依赖，达到提升开发效率和质量的目的。但业务需求的依赖是无法消除的，所以模块化方案首先要解决的是如何在无代码依赖的情况下实现跨模块通信的问题，无论是基于 NSInvocation 还是基于 peformSelector 方法, 都可以很很容易做到这一点。但不能为了解耦而解耦，提升质量与效率才是我们的目的。直接基于 hardcode 字符串 + 反射的代码明显会极大损害开发
目前的常见的模块间通讯方案这几种：
1 基于路由 URL 的 UI 页面统跳管理。
2 基于反射的远程接口调用封装。
3 基于面向协议思想的服务注册方案。
4 基于通知的广播方案。
路由URL统跳方案
大量应用于前端页面。通过把一个 URL 与一个页面绑定，需要时通过 URL 可以方便的打开相应页面。
有些场景会比这个复杂，页面需要更多的参数URL协议天然支持：
复杂类型参数，可提供额外的字典参数complexParams，把复杂参数放在字典即可;
URL 本身是一种跨多端的通用协议。使用路由URL统跳方案的优势是动态性及多端统一 (H5, iOS，Android，Weex/RN); 缺点是能处理的交互场景偏简单。一般更适用于简单 UI 页面跳转。一些复杂操作和数据传输，可以通过此方式实现，但都不是很效率。
目前天猫和蘑菇街都有使用路由 URL 作为自己的页面统跳方案，达到解耦的目的。
反射的远程调用与封装
当无法import某个头文件但是还是需要调用其方法的时候，就会想到用基于反射来实现了
可是这种方式存在大量的 hardcode 字符串。无法触发代码自动补全，容易出现拼写错误，并且这类错误只能在运行时触发相关方法后才能发现。无论是开发效率还是开发质量都有较大的影响。
怎么优化呢？
一般移动最常见的远程调用就是向后端接口发网络请求。这类问题，我们很容易想到创建一个网络层，将这类“危险代码”封装到里面。上层业务调用时网络层接口时，不需要 hardcode 字符串，也不需要理解内部麻烦的逻辑。我们可以在模块通讯封装到一个（网络层）这些危险代码一般只存在某个文件夹里面，可以特别进行code review 和联调测试后期可以通过单元测试来保障质量。模块化方案中，我们可以称这类“转发层”为 Mediator (当然你也可以起个别的名字)。同时因为 performSelector 方法附带参数数量有限，也没有返回值，所以更适合使用 NSInvocation 来实现。
今天文章点就先在这里，哈哈 期不期待下回的章节的呢，告诉你，不关注偶，不可能。
下回继续从架构设计方面深入，
