事件是从底层系统层向表现层发送的

UnRegisterOnDestoryTrigger挂到一个对象上，对象销毁的同时，时间也会相应注销

Command只能由表现层向底层系统发送

IUtility是一个单纯的接口，用于工具类继承，工具类中有具体的实现方法

Architecture中有注册接口，获取接口的方法

Model层负责管理数据，Utility层负责提供工具API，及提供API又有状态的代码放在System层

表现逻辑：当Model数据变更时，视图来显示变更后的数据；

交互逻辑：接收用户输入改变Model数据

有没有状态可以理解为这个对象需不需要维护数据

System层中有数据变量和方法

在表现层想要使用System的话，需要通过Command执行

System层的利用率针对不同的项目是不一样的，有可能使用率很高，也可能根本用不上

在构造函数中设定默认值，以及监听数值变化并存储

定义接口，定义继承接口的实现类

IOC容器的两个核心API，1.根据Type注册实例 2.根据Type获取实例

IOC容器中有一个字典，用于存储单例

Init交给子类去实现，并提供必备的注册方法给子类

正常实现接口的方法叫接口的隐式实现

接口的名字.方法，叫接口的显式实现

 注册接口，类继承接口后在类中实现方法，可通过注册接口，获取接口来得到实例

接口可以直接切换

静态类用于模块化非常方便

静态类没有访问限制

使用static去扩展模块，其模块的识别度不高

如果一个类是单例类，那么我们就可以比较容易识别，这个单例类是一个模块类

比较小的用委托（金币 分数 等级 经验值）

比加大的用事件（服务器拉一个任务列表数据）

委托的方式

开始先找到 按钮的组件

不要持有双向引用

父节点可以引用子节点 子节点要调用父节点的方法时 可以用事件或委托

但这个例子举得实在有点一般

这一步少了个演化步骤,本来整体可以缩减为IOC变量,Init()方法,Get()方法; 然后在写成模板的需求下,增加了一个mArchitecture变量和MakeSureContainer()方法,主要是为了用来调用非静态的抽象方法Init()

个人思考：

• Controller首次调用Architecture实现类.Interface时，框架中的Utility、Model和System才进行初始化，可能是为了体现有实际需求时再实例化Model、System和Utility各层的思想
• 初始化时由于可能发生引用为空的问题 以及 字典中还未添加相关Key-Value的问题，在MakeSureArchitecture方法中先将各层初始化；并将各层添加进字典中，然后再逐个调用Init方法，并且先调用Model的Init，再调用System的Init，这样避免出现System可能再一开始就需要Model的具体值，但由于Model未调用Init方法导致System取到的值为默认空值的问题。
• 各种Command并没有像Model、System和Utility直接在一开始就添加进字典，而是有需求时再生成调用。可能是出于Command一般会很多的考虑，没有将Command做成单例

表现层复用的逻辑可以用在系统层，比如计时系统和成就系统

模型层则负责数据的定义以及提供数据的修改方法

工具层则负责提供基础设施，比如存储方法，网络链接方法，框架集成等等

当上层要改变下层状态时必须要用command，只是简单查询则可以直接方法调用

由于IController没有对应的抽象Controller，所以IBelongToArchitecture的阉割需要在子类中实现

其实可以为项目制作指定的抽象类，但是为了框架的通用性，所以新项目需要自己去对应的类里进行GetArchitecter的阉割

这里其实有问题你看罗敏是个大二货、她终于想起来要给罗琳和姑姑买礼物了。你们说

ui和game节点

SceneManager.GetActiveScene().GetRootGameObjects();获得顶端节点