mPaaS iOS框架笔记3->从微应用看委托模式

我们来看一下阿里提供的参考文档中的类图：

参考这个UML图，我们可以看到；

微应用的委托协议与微应用的类是聚合关系；

我们根据这个图，来对委托模式进行一次梳理和理解：

我们来看一下，DTMicroApplication类和DTMicroApplicationDelegate协议，个人理解如下：

1.DTMicroApplicationDelegate协议中的方法与DTMicroApplication类密切相关，是DTMicroApplication类的对象的状态的回调；

（比如DTMicroApplication创建，启动，挂起等）

2.如果不使用DTMicroApplicationDelegate协议，将DTMicroApplicationDelegate协议中的方法放在DTMicroApplication类里，

感觉别扭：DTMicroApplication是一个静态的概念，实现自身状态的捕捉和回调感觉比较怪异（比如DTMicroApplication创建，启动，挂起等），且DTMicroApplication就会比较臃肿；

3.如果将DTMicroApplication类和一些自身状态的捕捉和回调的分开，职责的划分就比较清晰；

我们可以举一个生活中的例子：

DTMicroApplication好比是患者，而DTMicroApplicationDelegate是患者委托的医生；

患者不懂医术，但是他明白自己的需求，他将自己的需求以协议的形式发布出去（协议只有方法的定义，没有实现，方法的定义就是患者的需求，例如发烧怎么办，头痛怎么办，方法的实现由遵循协议的人实现）；

患者委托的医生，遵循了患者发布的协议；

医生将协议中方法进行实现，比如一旦发烧就吃某某药等；

这样，对于患者的需求，就由被委托的医生来处理；

我们回到开始的图：

1.DemoApp遵循发布的协议，这样，我们也是以DemoApp的委托对象实现相关的操作；

上面绿色的图准确的应该是DemoApp的委托对象而不是DemoApp自身；

2.因为应用及微应用的创建并不是由我们来完成，是操作系统或者框架来做，但是我们可以通过暴露出的接口（比如DTMicroApplication创建，启动，挂起等）来完成一些个性化操作；

这样我们操作的是应用的委托对象，而不是应用自身，也起到了间接访问，保护应用对象本身的作用；