iOS 开发-用设计模式重构登录模块

登录模块可能是很多开发者接触APP开发的第一个完整模块，相对其它业务模块，登录模块各页面功能定义明确，调用关系比较清晰，一般以登录页面为主页面，push到各个页面即可：

简化的登录关系图

这是大部分登录Demo描述的场景，真的如此吗？想一下常见的APP，比如京东，什么时候会出现登录页面？答案是：任何页面！ 只要你没有登录，“签到”会跳转到登录，“购物车”会跳转到登录，“消息中心”会跳转到登录，我们这里统一称为“发起页”：

优化前的实际登录关系图

从发起页进入登录模块时，考虑了以下情形：
a) 入口不一定是登录页，也有可能是重置密码（如：个人中心），也可能直接到注册页（为简化，图中略去）。
b) 从任何子页面都有可能直接回到发起页，图中用虚线标示，比如进入注册页后，用户不想注册了，这时应该退出整个注册流程，直接回到发起页。

不难发现，为了考虑多种情况，登录模块中的每个页面都需要知道其它页面的情况，与其它页面产生了强关联，“登录”需要知道“重置密码”、“注册”、“第三方注册”，连作为调用者“发起页”也不能幸免，如上图情形，就需要关联“登录”和“重置密码”；如果这时候需要添加“用户信息”，就需要修改“发起页”、“验证码”、“第三方登录”等等页面，导致整个模块修改困难。

这种系统的各个对象之间的相互关系成网状结构的情形，就是中介者模式大显身手的时候了：

这种模式提供了一个中介类，该类通常处理不同类之间的通信，并支持松耦合，使代码易于维护。中介者模式属于行为型模式。

我们引入“VC管理器”，各页面只和该管理器发生联系，需要跳转到哪个页面，只需要告诉管理器“目标页面名称”即可，无需知道具体的页面类：

引入中介者后的各页面关系如图：

优化后的登录关系图

“VC管理器”中，将显示的VC用栈结构来保存，方便我们处理返回或直接关闭逻辑。
通过引入“VC管理器”，我们获得了以下好处：

1. 减少各页面之间耦合，可以灵活的显示模块中各个页面。
2. 统一管理了各个页的跳转关系，减少了各页面处理页面跳转的冗余代码。
3. 方便添加新页面。