结构演化小结
架构演化顺序复盘
对象之间的交互
首先按照一次性项目的方法快速完成了《点点点》项目的制作。
分析了《点点点》项目后发现有三个问题，总体来说其实是一个问题：
- 对象之间的引用无规则
针对这一点，我们先使用树结构来整理了一下场景结构（UI、Game），然后引入了对象之间的交互这个概念。
对象之间的交互有三种，分别是：
- 方法
- 委托
- 事件
然后也简单说了下模块化的三种常规方式
- 单例
- IOC
- 分层
接着，我们通过对象之间的三种交互方式，逐个修复了《点点点》遇到的问题。
最后总结得出
- 自底向上用事件或者委托
- 自顶向下用方法
在这个过程中，我们积累了一个工具类，即：Event基类。
再接着，我们学习了一些理论，包括：
- 表现和数据要分离
- 交互逻辑与表现逻辑
然后分别开始对《点点点》以及《CounterApp》的表现逻辑和交互逻辑进行优化。
表现逻辑优化时引入了一个工具类BindableProperty，它是数据+事件的组合。
交互逻辑优化时引入了Command模式，它是大部分MVC框架的选择。
Command是对象之间交互的第四种方式，不过它适用于交互逻辑。
到此，对象之间的交互这个话题就结束了，加下来开始介绍模块化了。
模块化
最开始能够模块化的对象是我们两个项目中的Model对象。
因为Model对象是需要再多个表现对象之间共享。
而最初Model对象是用静态类实现的，后来我们引入了单例，单例比静态类好一点就是其声明周期相对可控，而且访问单例对象比访问静态类多了一点限制，也就是需要Instance的获取。
模块化方面和对象之间的交互方面要考虑的问题是差不多的，模块化方面，就是访问模块对象的方式是不能无任何规则和限制的。
所以针对这一个问题，引入了限制性较强的IOC容器。
引入IOC容器后，我们可以通过模块接口去访问模块对象，在设计模块的时候，可以先设计接口，再设计模块对象。
分层
但是IOC容器在使用的时候，本质上和静态类和单例是一样的，所以这里我们引入了层级这个概念，逐步把整个项目分成了IController、
ISystem、IModel、IUtility四个层级，并且实现了Architecture基类。
期间我们接触了接口阉割技术，在之后我们通过接口阉割技术和静态拓展方法，为每一个层级都增加了限制。
最后我们又引入了TypeEventSystem，并且也为它增加了使用规则，用来作为架构中主要的事件系统。
Controller层（表现层）：获取System，Model、监听事件、发送Command（BelongToArchitecture）
Command（中介）：获取Utility，Model，System、发送事件、发送Command（BelongToArchitecture , CanSetArchitecture）
System层：获取Model，Utility，System、监听事件、发送事件（BelongToArchitecture , CanSetArchitecture）
Model层：获取Utility、发送事件（BelongToArchitecture , CanSetArchitecture）
Utility层：无
