机房收费系统-设计模式思忖
机房收费系统--设计模式思考
今天与阿真同学简略讨论了一下外观模式和抽象工厂+反射+配置文件在机房重构中的应用，引发了几个简单的思考，现与君共勉：
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层出现了很多逻辑判断，反过头来思考才能意识到这些设计模式的妙处，相信对接下来的设计模式的应用学习会更加灵活方便。
- 19楼u012704843昨天 22:17
- 设计模式很有魅力的。。
- 18楼u013033838昨天 22:19
- 学习还是要多思考呀！
- 17楼u010924878昨天 21:34
- 点点滴滴，汇江成海
- 16楼successA昨天 21:05
- 多尝试。
- 15楼u013046597昨天 20:50
- 外观模式我一开始用了，但是后来就觉得没有必要就不用了，看来是理解的不够深刻
- 14楼u013045437昨天 19:36
- 不断总结，不断进步
- 13楼u013036685昨天 17:08
- 将模式熟练的应用的重构中。
- 12楼u013028876昨天 14:48
- 实践出真知。理论要经过实践才能更好的理解与运用。加油
- 11楼u013036688昨天 14:23
- B层为什么觉得按照数据库表来划分比较合理？n我一开始是按照功能来的，后来发现还是按照数据库来更方便
- 10楼u013036278昨天 14:21
- 不断学习，不断总结
- 9楼u012308971昨天 14:10
- 善于思考，想你学习。
- 8楼u013086062昨天 13:56
- 点点滴滴的积累带来巨大的改变
- 7楼u010924878昨天 11:01
- 点点滴滴，汇江成海
- 6楼u013068440昨天 10:54
- 不断总结，不断进步。
- 5楼u013043518昨天 10:43
- 我还暂时不能理解外观带来的效果呢。
- 4楼u013035612昨天 10:29
- 很新颖的想法。
- 3楼u013047684昨天 09:55
- 设计模式就是解耦的，变现在代码的优化上，多多看书。
- 2楼u010858791昨天 09:16
- 博客已阅读，很不错呀 赞
- 1楼u012581322昨天 08:50
- 对于设计模式的学习简直是无穷啊