今天与阿真同学简略讨论了1下外观模式和抽象工厂+反射+配置文件在机房重构中的利用，引发了几个简单的思考，现与君共勉：
思考再3：B层方法是实现对数据表的增删改查进行逻辑操作，而且还要斟酌解耦效果（我是这么理解耦合的，如果1个类中只放1个方法，1旦出错，它只影响自己，耦合度就低；如果有10个方法，1个方法出错，该类的实例化就会出错，这样耦合程度就越强），所以B层的类中放的方法不应太多；斟酌到每一个窗体大部份都是对1张表进行的操作，这样，将每张表对应的增删改查操作放到1个B层类中，大部份调用时只需要实例化1个B层类就能够实现对全部窗体的操纵任务，既减少程序履行流程，又减轻电脑负担，何乐而不为呢？
2. 外观层可不可以用1个类来实现呢？对照于1个窗体1个facade类有甚么区分？外观类依照数据表来分有甚么坏处？
讨论想法：外观类先对方法实例化然后再调用的，每实例化1次，相当于把外观中用到的类都实例化了1次，不管是用到还是没有用到的。
如果facade用1个类实现所有B层方法，那末20多个窗体每一个窗体调用都要实例化1次facade类，就是B层所有的方法都调用了20屡次，造成大量无用程序的履行。
1个窗体1个facade类，用到facade类中实例化的方法都是马上要用到的，这样所有B层方法实例化次数大大下降，基本上就是每一个履行1-⑵次，这样电脑的负担不会很大了。
还是一样的分析方法，虽然B层方法不会调用屡次，但诸如上机结账等窗体不止用到1张表，而恰恰Facade类也是依照表分的，那末对Facade类的调用次数必将会增加。
3. 抽象工厂+反射+配置文件的利用优势
说到工厂家族，难免会想到它们对switch语句的钟爱，但如果数据库表的数目过于庞大，又要求可使用不同的数据库切换时，swtich难免会增加许多无谓的判断，这样通过工厂+反射+配置文件的方式，实现对D层方法直接调用，同时容易实现对数据库的切换。
【总结】
在机房设计早期只是听说这些设计方法和设计模式就直接加以利用了，而且对外观模式利用认识不到位，致使U层出现了很多逻辑判断，反过头来思考才能意想到这些设计模式的妙处，相信对接下来的设计模式的利用学习会更加灵活方便。