个人重构机房收费系统小总结

    个人版机房收费系统总算是完事儿了，会看这一段历程真是感慨啊。开始的一段时间，写着三层，感觉好难啊，当时看着三层的实例，自己也敲过了。但是总是憋不出来，总是想不出来更写不出来。慢慢的慢慢的试着通过其他人的博客，查资料。自己能写出了三层的登录窗体。当自己三层写完的时候回头加设计模式，又是一头雾水啊，说句实在的设计模式都不理解呢，就更别说在登录窗体中加模式了。

    在重构的时候，对于数据库也是困难啊，对于数据酷三范式虽然知道了，字面上是理解了。但是总是写不出符合机房收费系统而且又符合三范式的数据表。

    馒头的一口一口吃，困难的一各一个的克服，看同学博客，和同学交流，这才终于能够走动了。

    在敲系统的后半阶段，会看自己敲的系统感觉漏洞百出啊，哪儿有符合面向对象的设计，类用的是一塌糊涂。在用三层的时候加进设计模式应该能够减少代码的复用以及类与类之间的耦合。

    原因分析，关于个人惰性的问题这里就不想多说了，对于技术的问题，我写的过程中先写了几条线儿，然后敲的系统感觉可以了就没有画图而是一股脑的敲完了在回头照着已经敲好的模式去画图。原因就出在这里，导致在敲系统的时候没有很好的把握好全局观。现在回想起来感觉除了UI层不用改生下的都需要动手术。首先说一下D层，因为有一个SQLHELPER减少了连接数据库代码的复用，用一个表创建一个类来代替以前凌乱的根据窗体来创建的类。这样就减少了D层窗体的创建而且在通过调用的过程中能够比较灵活的调用使用目的表。而如果按我已经敲过的系统来使用这样针对比较小量的窗体而言比较合适（但是对于比较小软件用到的数据表肯定也不会多，所以还是针对表建立D层类合适，说来说去我建的就一垃圾啊），对于机房收费系统事实证明铁定不合适了。在谈B层，对于B层而言相对来说就比较简单了，无非就是调用D层的方法，有些窗体需要使用多个数据表，这些通过外观模式的方式来减少U层与D层之间的耦合，这样就只需要通过几个类甚至一个类来完成U层要实现的功能了。