一：前言

有了上面两节的知识，尤其是第六节之后，现在我们回过头看我们的打老鼠游戏，我们是不是会发现：这个程序也太不面向对象了。我们所有的代码逻辑都分布在Code-Hide中（UI的后台代码，称之为Code-Hide）。并且，UI的后台代码又负责显示，又负责游戏逻辑的，这也直接违反了，

1：面向对象编程中的封装原则。有时候，在面向对象编程中，还有人会说到，让一个类只干一件事情，我们的前台类干的事情太多了；

2：分层原则。我们也一定听说过三层架构。等等，我们的程序跟三层架构有什么关系？容我慢慢跟你道来；

3：开闭原则。什么是开闭原则，不着急，这些所谓时髦的名字是故意弄出来吓人的，我们学习完这小节，你就自然懂得什么是开闭原则了。

好的，既然我们的小游戏出现了这么多问题，看来，现在是到了该重构我们的小游戏的时候了。

二：视频

非公开部分，请联系最课程（www.zuikc.com）。

三：小步重构之游戏逻辑独立出来

总结一下这个视频，在这个视频中，我们学到了，

1：按“意愿”去实现代码。什么是按意愿实现代码呢，大家会看到我会在一个实现还没有在代码中的时候，就已经顺着我们的逻辑将引用写好了。我会将引用或者调用写好，然后按“Shift+Alt+F10”，让VS自动去帮我们实现代码；

2：让每个类去完成自己的事情，Code-Behind只负责显示相关，GameProcessor去完成游戏相关的逻辑；

3：GameProcessor想让Code-Behind实现的事情，交给委托去做；

4：只开放必要的逻辑给外部类。比如Score这个属性，Set被设定为private；

当我们把我们的逻辑独立出来之后，在打老鼠这个游戏中，之前隐藏的那些BUG也已经不存在了。我一直不急于去修正这个BUG就是这个道理。因为我知道，我们迟早要重构这个代码，把这个代码变的漂亮一点，简单一点，到时候，我们的这个BUG也许自然就被解决掉了。

四：完善继承体系

在上一步的小步重构之中，我们将初级难度的游戏逻辑给实现了，紧接着，我们就要实现中等级以及高等级难度的游戏逻辑了，那么，我们是不是还是要在GameProcessor中去实现呢？错。

我们还记得在之前的逻辑中，对于难度的判断是通过一个枚举来实现的。当我们的代码中出现枚举的时候，我们都应该停下来好好想一想，是不是到了应该引入继承的时候了，比如，等级从简单到难的过程，我们完全可以实现为三个GameProcessor的子类。这就是开闭原则：

即，对扩展开放，对修改关闭。

这貌似有点不好理解，不妨看看我们的代码是怎么实现的吧。

我们最终实现的这些代码的UML类图如下：

五：视频

非公开部分，请联系最课程（www.zuikc.com）。

六：分层还有工厂

什么是层？实际上层这个概念并没有这么可怕。以整理衣物为例（虽然我知道很多程序员几乎从来不整理衣物，但是见总归见过吧，老婆的，妈妈的，她们总归整理过衣服），实际上，整理衣物就是一个分层的过程。我们将代码分类，丢到某个固定的位置去，就叫分层。

很多人问，什么是三层架构，无非就是数据访问的代码，放到某处，分为一层。控制逻辑或者业务逻辑，又分为一层，等等。分层实在是最基础的东西，即便是我们的小游戏，现在也到了分层的时候了。

在做这个分层的时候，我们还发现，原来我们创建各个子类的代码是可以被归类到一个叫做ProcessorFactory的类中去的，作为UI来讲，我们可以只要传入“Basic”，那么这个工厂就会为我们生成一个BasicProcessor的对象，如果传入“High”，那么就会返回HighProcessor对象。这样子，我们就不知不觉的学了一个设计模式，它叫什么呢，它就是工厂方法，它的UML类图如下：

下面这个视频我们来看看如何一步一步的实现分层以及工厂：

七：视频

非公开部分，请联系最课程（www.zuikc.com）。

八：总结

继续来总结一下该视频，除了

1：分层和工厂之外；

我们还学习到了：

1：为解决方案添加新的项目；

2：让一个项目引用另一个项目；

3：让一个项目引用FCL；

4：如何来展现我们的代码（UML）；

TIP：本节的内容有点多，视频内容加起来有1个多小时，我希望通过本节的学习，我们能够掌握让代码写的相对较为整洁的技巧。我们能大致掌握分层的原则，能大致掌握封装的原则。