一：前言
有了上面两节的知识，尤其是第六节之后，现在我们回过头看我们的打老鼠游戏，我们是不是会发现：这个程序也太不面向对象了。我们所有的代码逻辑都分布在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个多小时，我希望通过本节的学习，我们能够掌握让代码写的相对较为整洁的技巧。我们能大致掌握分层的原则，能大致掌握封装的原则。
本文基于
Creative Commons Attribution 2.5 China Mainland License发布，欢迎转载，演绎或用于商业目的，但是必须保留本文的署名
http://www.cnblogs.com/luminji（包含链接）。如您有任何疑问或者授权方面的协商，请给我留言。
