的房费重构——上，下位机的复议

        有一种说法叫no zuo no die，我可能喜欢它的人。why?

充电系统时，腾出空间，可以根据实现的一般方法，时候，总感觉这么做对自己来说，没什么提高。然后就停下来，又一次想想上下机还能怎么做？

        后来，大致採用的思路是这种：将上下机的读写数据的过程写成两个存储过程，负责读取和更改数据。中间的计算过程写在代码里面：中间推断时间的过程用职责链模式来实现，推断一般用户还是暂时用户用策略模式实现。这样。整个上下机的过程就是这种：

       1。用上机的存储过程使学生上机，然后将学生上机信息写入表中，最后返回上机信息，用来显示在主窗口上。

       2。下机时，通过两个模式，传入參数时间和用户类型计算出上机花费的钱；

       3，调用下机的存储过程，将学生上机过程的信息写入，然后返回下机信息。

    分成这3步后，将上下机过程分开了，假设算法修改，也不用更改两个存储过程，仅仅需更在模式里面加即可了。所以。中间算法增加了设计模式后。它的主要作用还是去除选择和便于扩展。

     计划好之后，就開始做个Demo.首先写完了两个存储过程，这个就不说了。

然后是做上下机的Demo,

    例如以下。client调用代码：

   

    观察后发现，如今还是做个小样例，假设真的加到上机里面去。感觉写起来非常麻烦，我记性不好，会忘掉的。还是再抽像下吧。我最喜欢的调用还是给出用户类型。基本数据，上机时间，然后剩下的什么也不写了，就直接得到上机花费的钱。

   so,再加个类：

   将这个过程封装进去，然后再调用就成了这样子：

 

  这个类有点儿类似外观模式那样的控制效果，可是由于没有非常多要控制的对象。所以，仅仅要一个类即可了。

  近期做机房收费系统感觉到了一个“欠思考”的阶段，模式用的太少，还没有锻炼到自己，继续加油！

   

    

版权声明：本文博客原创文章，博客，未经同意，不得转载。