3消游戏跟着智能手机流行到现在已经有很长一段时间，unity实现的3消 https://github.com/textcube/match3action
截图如下：
在阅读源码的时候不难发现，GameSystem所负责的东西太过繁重，很多时候总是要很费力去分清哪些是对ui进行处理，哪些是进行数据处理，哪些又是在进行逻辑判断。
源码类图如下：
要注意的是，Cell是引用类型。 MatchItem 里面所存放的cell，和GameSystem中所存放Cell[,]对应的cell项是指向同一内存地址的。修改其中一个会影响到另外一个。稍不注意便会引发错误。
于是尽管源码条理清晰，命名规范，还是决定动手重构。
大致方向是抽象多一个数据操作层CellDataManager出来,进行数据初始化，检测是否符合三消条件，数据交换等操作，供GameSystem。
关于分层，开发群里面有个“演员”的比喻可以跟大家分享一下：
“只把u3d的东西当作显示对象来用的话,就没必要太过纠结.
逻辑对象和显示对象身份不混合,各干各的,相安无事.
比如说碰撞，有一种方法叫代理碰撞检测,就是演员在这演着,在看不见的地方,只有几个粗糙的布偶在做碰撞的交互,一旦有交互同步告知演员即可.
虽然各个问题都需要具体分析.不过能把各个问题清晰的分开,就不要混在一块儿,混了之后妄图通过什么设计模式来解决是行不通的.”
在3消游戏里面也是差不多的道理：
底层一个2唯数组存放着信息，在进行ui操作的时候调用对应的 数据操作api。判断是否符合3消条件，符合返回消除项的id，进行对应的ui逻辑处理，不符合则进行其他ui处理。
重构后类图如下：