有句话叫做no zuo no die，我大概就是这种人吧。why?做机房收费系统的时候，按照一般方法也能实现，但这次做上下机的时候，总感觉这么做对自己来说，没什么提高，然后就停下来，重新想想上下机还能怎么做？
后来，大致采用的思路是这样的：将上下机的读写数据的过程写成两个存储过程，负责读取和更改数据。中间的计算过程写在代码里面：中间判断时间的过程用职责链模式来实现，判断一般用户还是临时用户用策略模式实现。这样，整个上下机的过程就是这样的：
1，用上机的存储过程使学生上机，然后将学生上机信息写入表中，最后返回上机信息，用来显示在主窗体上；
2，下机时，通过两个模式，传入参数时间和用户类型计算出上机花费的钱；
3，调用下机的存储过程，将学生上机过程的信息写入，然后返回下机信息。
分成这3步后，将上下机过程分开了，如果算法改动，也不用更改两个存储过程，只需更在模式里面加就行了。所以，中间算法加入了设计模式后，它的主要作用还是去除选择和便于扩展。
计划好之后，就开始做个Demo.首先写完了两个存储过程，这个就不说了。然后是做上下机的Demo,
如下，客户端调用代码：
观察后发现，现在还是做个小例子，如果真的加到上机里面去，感觉写起来很麻烦，我记性不好，会忘掉的。还是再抽像下吧，我最喜欢的调用还是给出用户类型，基本数据，上机时间，然后剩下的什么也不写了，就直接得到上机花费的钱。
so,再加个类：
将这个过程封装进去，然后再调用就成了这样子：
这个类有点儿类似外观模式那样的控制效果，但是因为没有很多要控制的对象，所以，只要一个类就行了。
最近做机房收费系统感觉到了一个“欠思考”的阶段，模式用的太少，还没有锻炼到自己，继续加油！
机房收费重构——关于上下机的再思考,布布扣,bubuko.com
原文：http://blog.csdn.net/lhc1105/article/details/30713331
