房间计费系统的改造已经开始了很长一段时间，随着最近两天感觉有点线索。
对这次重构。刚開始计划的是先做数据库，然后优化下，列出每一个窗口对表的訪问关系，抽出经常使用的訪问作为存储过程，然后把訪问数据库的经常用法封装成SqlHelper.这部分就是数据库的部分。
然后就是软件的结构：总体上是分了七层：三层+实体+外观+抽象工厂+D层接口。尽管计划的非常好。可是在详细分层这里想了非常久。
最先是对D层開始下手的。D层是什么？是对表的訪问，将对数据库的读取和写入都封装成D层的类，那么。类又依照什么分呢？后来想了想曾经学习三层的时候做的7层的登陆窗口，那个时候，D层是依据表来的，将訪问每张表的方法总综合写成一个类。
在纠结中，顺便进行着考试系统的測试。中间夹着这学习了非常多东西，感觉还是挺充实的，尤其是看了十几集的牛腩视频。给了我非常多启示。最终在一个周六，画了一天类图。让看到了自己纠结非常久的成果了：
对于D层：基本是依照表来，将表抽象出一个类或者几个类，在每一个类里面，尽量让全部的方法去訪问表中同样的字段，也就是说。尽管D层主要依照表来，可是也用功能去辅助分类，比方，对于訪问两张表的情况。就将这种方法依据功能放在相似与他功能实现上有联系的类中。
做完D层之后，向上到了接口层，才发现慘了。事实上我应该先做接口的。由于D层是用来实现接口层的，而不是接口层依据D层出现的。也就是说。编程要面向接口。唉。当时怎么就没想起来呢？
接着做的是实体层。实体层是做什么的呢？先想想我们曾经程序中是怎样传递数据的：我们比方。我们注冊一个学生。这个学生可能写到学生信息表里面有十几条字段值要写进去，传递过程中在程序内部写这么多的值是非常easy丢掉一两个的，有了实体层。我们能够非常好的发挥封装的作用，将全部数据打包传递。就像给你寄个快递一样，不管多大还是多小，都给你打个包，不至于丢失什么东西。
对于抽象工厂，延续抽象工厂+反射+配置文件的高大上的做法，返回接口，后来写代码的时候，发现修改起来果然很easy。当我修改D层的时候，上面的东西根本不用动。
接着是B层。对于B层。它接收从U层过来的数据，向下送到D层进行处理，并将D层返回的数据放在这里进行推断和处理，并将结果返回给U层。可是它是怎样进行分类的，这个问题想了好久。看大家博客和当面交流，大家都大致是这样做的：1，依照U层窗口来。2。依照用例来；。。。。事实上我是比較看好依照用例来的。由于假设U层有非常多窗口的话，会造成B层类过多。
可是依照用例来也是有问题的，假设我添加功能，就要去修改类。
好像怎么着都不完美。后来。想到设计模式上说的一句话：不论什么需求的变动都是须要成本的。我认为如今这个阶段我还是选择一种方法做下去比較好，假设实现的过程中。发现了更好的方法，能够再去修改。
对于外观层。是对B层的进一步抽象，这次做到最后的时候，去掉了外观层，由于感觉这个系统太小了。B层的抽象程度已经相当高了，加了外观层就是冗余 了。
这样。仅仅剩下最后的U层。它仅仅用来实现主要的输入输出就能够了。
解耦完成~~~~
版权声明：本文博客原创文章，博客，未经同意，不得转载。