关于设计模式与框架的一点思考

为什么使用设计模式？也许你的回答会是：提高设计的重用度、灵活性、可维护性等等。但是我认为更准确的回答应该是：解决系统设计中现有的问题。

大家都会有个疑问：23种模式感觉上一样啊，有什么区别啊。其实这是很正常的，面向对象设计、编程所能使用的方式不外乎这几种：继承、组合、封装行为、利用多态等等，23种模式在解决问题上的手法是如此的相似——添加间接层以解耦。其实何止模式如此，我们所接触的很多技术都是采用这种添加中间层的手段，如：J2EE的分层技术、重构等等。所以23种模式中翻来覆去的使用这几种方式，看起来当然是似曾相逢。

再深入一层细看，在设计模式中，广泛遵循了两条设计原则：面向接口编程，而不是实现；优先使用组合，而不是继承。

框架在加速开发效率的同时，也把软件工程师变成了代码组装工。

越来越方便的框架支持，领域模型简化造成代码过程化、脚本化，使得在企业应用中很难看到原始设计模式的影子。比如：IoC容器将单例、工厂、原型模式包装了起来，你现在需要做的仅仅是填写配置文件；框架集成了观察者、模版等等模式，你仅仅按照框架说明实现具体对象就可以了；过程化、脚本化的代码里面更不要提什么设计模式了！

不仅如此，由于开发者的设计能力不够，所以导致了在实践中由于需求的剧烈变化，预先的设计反倒成了项目开发的绊脚石。于是极限编程XP横空出世：既然没有那个预见能力，干脆就不需要任何设计，一切都被需求牵着鼻子走，走到哪算哪。对很多粗略接触到极限编程的人来说，XP似乎宣告了软件设计的死刑。不仅有很多的设计被嘲笑为“臃肿的预先设计(Big Up Front Design)”，就连很多设计技术，像UML、灵活的程序架构(framework)，甚至连模式(pattern)都不再受到重视甚至被彻底的忽略了。

原始的设计模式没有用，过时了吗？如果只是浅层开发，设计模式当然就用不上了，这就像1+1这种等级的算法当然用不上高等数学。但是对于高级开发，了解它们绝对不是在浪费你的时间，它可以让你在解决问题的时候思路更开阔一些——它的思想比它的架势更重要。