一个体现Java接口及工厂模式优点的例子- -

随着模式概念的普及，了解模式和使用模式的程序员越来越多，很多人在学习模式的时候，都会有这样一种疑惑：“有必要搞得这么复杂吗？”。的确，因为教程的例子过于简单化（这样方便读者学习），或者是作者选例子的时候并没有很好体现所讲模式的优点，很多情况下如果仅就其例子的问题来说，用模式是太复杂了。因此才导致这样的误解：“模式就是把简单的问题复杂化吗？”。当然不是，随着你开发实践的不断丰富，你终会发现模式强大威力，而且模式也并非贵族化的编程方式，它就是一些经过提炼了的解决问题的方法技巧。

通过学习模式，程序员开始告别过去准直线式的代码方式，模式开扩了我们的视野，强化了我们面向对象编程的思维方式。然而现在又出现了另一个普遍的问题，盲目应用模式。模式是问题的解决方案，先有问题才有模式，模式是依附于所要解决的问题的而生的。必须了解模式在很多情况下是以提高代码的复杂度为代价来增强灵活性、可复用性。如果在自已的代码中使用某一模式仅只提高了代码的复杂度，而其它方面收效甚微，或者某部份代码根本就不存在灵活性及高复用性的需求，那么我们就没有必要为使用模式而放弃更直观简单的代码写法。

一流的高手90%精力关注问题的解决方案，因为找到了好的解决方案，再写起代码会很轻松代码也简洁流畅，看这样的代码是一种享受和提高；二流的熟手90%精力关注代码实现，因为问题的解决方案并非最佳，实现的代码也会比较复杂；三流菜鸟记流水帐,90%精力在敲键盘，常常做了大半才发现行不通，回过头来再用90%的时间敲键盘，根本不会用到任何模式，写出来的代码的只有他自已才能看懂。做出来的软件也是支离破碎，做一丁点改动都要大费周折，而且你还不知道改动后会产生什么问题，大有住危房里的感觉。

在这里还是举一个滥用模式的例子吧。我曾参与过一个大集团公司ＯＡ系统的第二期开发，开发沿用原有代码架构并增加新的功能模块。文档很少我读原代码时就被它程序里的代码转来转去搞得头大如斗，最后读懂了：原代码架构总体采用工厂模式，而且是最复杂的抽象工厂模式。它把所有模块类都通过工厂生成还工厂套工厂，并且每一个模块类都有一个接口，每个接口也只有一个模块现实类，因为涉及权限控制还用了代理(proxy)模式。　读懂代码后我开始嵌入代码，发现每新增一个类，都要到六个Java文件中去增加相应代码，而在类中每增加一个方法，也要到它的接口等四个Java文件中去增加相应代码。天呀！！！记得当时我的小姆指常会不听使唤，就是因为频繁的使用Ctrl+C 、Ctrl+V，小姆指按着Ctrl键给累的。整个项目组苦不堪言，真烦透了。项目结束后我回顾发现：代理模式用得还对（现在针对权限这类横向控制有AOP编程这种新的解决办法了）但工厂模式在这里根本就是画蛇添足，不仅没有解决什么问题，反而增加代码复杂度和耦合性，降低了开发效率连维护难度都提高了。而且那种每个类简单的加一个接口的方式，更是没有道理，这让我很想说周星驰说过的一句话：“球~~~不是这么踢~~~~的，接口~~~不是这么用~~~的”。言归正传，我们先来看这样一个常见问题：某系统需要支持多种类型的数据库。用过Oracle、MSSQL等数据库的人都知道，它们的SQL编写方式都各有些不同。比如说Oracle的唯一标识自动+1字段用的是序列，MSSQL改一下字段属性就成了，还有各种各自特有的SQL用法。为了支持多数据库，难道我们要开发多套系统？当然NO。请看下面的解决方案。