机房收费系统--设计模式思考

         今天与阿真同学简略讨论了一下外观模式和抽象工厂+反射+配置文件在机房重构中的应用，引发了几个简单的思考，现与君共勉：

        1. B层为什么觉得按照数据库表来划分比较合理？

       

        思考再三：B层方法是实现对数据表的增删改查进行逻辑操作，而且还要考虑解耦效果（我是这么理解耦合的，如果一个类中只放一个方法，一旦出错，它只影响自己，耦合度就低；如果有十个方法，一个方法出错，该类的实例化就会出错，这样耦合程度就越强），所以B层的类中放的方法不应太多；考虑到每个窗体大部分都是对一张表进行的操作，这样，将每张表对应的增删改查操作放到一个B层类中，大部分调用时只需要实例化一个B层类就可以实现对整个窗体的操纵任务，既减少程序执行流程，又减轻电脑负担，何乐而不为呢？

      2. 外观层可不可以用一个类来实现呢？对比于一个窗体一个facade类有什么区别？外观类按照数据表来分有什么坏处？

       讨论想法：外观类先对方法实例化然后再调用的，每实例化一次，相当于把外观中用到的类都实例化了一次，无论是用到还是没有用到的。

       

       如果facade用一个类实现所有B层方法，那么20多个窗体每个窗体调用都要实例化一次facade类，就是B层所有的方法都调用了20多次，造成大量无用程序的执行。

      一个窗体一个facade类，用到facade类中实例化的方法都是马上要用到的，这样所有B层方法实例化次数大大降低，基本上就是每个执行1--2次，这样电脑的负担不会很大了。

      还是同样的分析方法，尽管B层方法不会调用多次，但诸如上机结账等窗体不止用到一张表，而恰恰Facade类也是按照表分的，那么对Facade类的调用次数势必会增加。

     3. 抽象工厂+反射+配置文件的应用优势

        说到工厂家族，难免会想到它们对switch语句的钟爱，但如果数据库表的数目过于庞大，又要求可以使用不同的数据库切换时，swtich难免会增加许多无谓的判断，这样通过工厂+反射+配置文件的方式，实现对D层方法直接调用，同时容易实现对数据库的切换。

【总结】

        在机房设计初期只是听说这些设计方法和设计模式就直接加以应用了，而且对外观模式应用认识不到位，导致U层出现了很多逻辑判断，反过头来思考才能意识到这些设计模式的妙处，相信对接下来的设计模式的应用学习会更加灵活方便。