设计模式不能做什么
2005-08-01 13:17
666 查看
GOF指出了设计模式能够解决的问题,但是设计模式也不是万能,什么都可以做,肯定有他不能做的事情或者是用了设计模式却适得其反。
1.设计模式不是法则
模式理论的精髓之一就是模式的使用是有前提和代价的,模式是在某种前提下,综合各方面的因素考虑得出的结果。即在使用模式时总要付出一定的代价的,当然这种代价是可以接受的。如果某个模式在所有场合的使用都是必然的,那么它就不叫设计模式了,而是必须遵守的法则。例如“面向借口,而非实现编程”是法则而非模式。
模式实际上是某种语境下的解决方案。在实际的项目中,是否采用模式取决于项目是否符合模式的语境,并且是否可以接受使用模式多带来的代价。很多情况下,模式的选择不是必然的。有时可以不采用模式也可以很好地解决问题:有时可以采用一种模式代替另一种模式,或者说在特定的语境下模式的使用不是唯一的。例如命令模式将行为抽象为类,模式的实现比较简单,也容易理解。那么这个模式是否可以在所有场合使用呢?显然不可以。如果我们把所有类的方法都抽象为命令模式,这样程序是最灵活的。因为可以动态地增加行为,但代价是程序中各个类就不再具有业务含义。业务含义全部隐藏在命令对象中,这样做的结果是晦涩难懂,可维护性降低。
2.不能提高开发速度或者形象开发速度
如果一个开发周期作为考核标准,恐怕没有人会使用设计模式,设计模式并不能提高目前的开发速度,至少其关注的目标并不是开发速度,很多情况下甚至会降低开发速度,即使是使用正确的设计模式。
这是因为设计模式可能会引入更多的对象和更复杂的对象装配关系,从而使得程序有更多的动态,从局部看来变得结构复杂,难以理解并且测试困难。如果仅仅关注于形象进度,或者能够百分之百地确定需求没有变化,那么设计模式并不是很好的选择。
然而,如果从整个项目和生命周期来看,合理地使用设计模式可以使程序结构更为健壮,更具有可维护性。千万不要相信需求不会发生变化,也不要相信两周后即可完成开发。很多项目表面上早就完成,可是离开了开发人员,业务则无法进行。于是,打着维护的旗号,一直在修修补补。如果你想真正摆脱用户的纠缠,那么在设计时就不要吝啬时间和精力,健壮的结构往往会使项目能更快(从整个周期来看)完成。
3.不是万能的
设计模式的使用时自然而然的事情,很多情况下不使用设计模式是因为不需要,问题还没有复杂到非用不可的程度。我们是为了设计而使用设计模式,而不是为了使用设计模式而设计。
当你的项目发现有如下问题之一时,就需要考虑重构代码,可能会有某种模式适合。
(1)代码无法进行单元测试时;
(2)需求的变动总是导致代码的变动;
(3)由重复代码存在;
(4)继承层次过多;
(5)隐藏的以来过多;
1.设计模式不是法则
模式理论的精髓之一就是模式的使用是有前提和代价的,模式是在某种前提下,综合各方面的因素考虑得出的结果。即在使用模式时总要付出一定的代价的,当然这种代价是可以接受的。如果某个模式在所有场合的使用都是必然的,那么它就不叫设计模式了,而是必须遵守的法则。例如“面向借口,而非实现编程”是法则而非模式。
模式实际上是某种语境下的解决方案。在实际的项目中,是否采用模式取决于项目是否符合模式的语境,并且是否可以接受使用模式多带来的代价。很多情况下,模式的选择不是必然的。有时可以不采用模式也可以很好地解决问题:有时可以采用一种模式代替另一种模式,或者说在特定的语境下模式的使用不是唯一的。例如命令模式将行为抽象为类,模式的实现比较简单,也容易理解。那么这个模式是否可以在所有场合使用呢?显然不可以。如果我们把所有类的方法都抽象为命令模式,这样程序是最灵活的。因为可以动态地增加行为,但代价是程序中各个类就不再具有业务含义。业务含义全部隐藏在命令对象中,这样做的结果是晦涩难懂,可维护性降低。
2.不能提高开发速度或者形象开发速度
如果一个开发周期作为考核标准,恐怕没有人会使用设计模式,设计模式并不能提高目前的开发速度,至少其关注的目标并不是开发速度,很多情况下甚至会降低开发速度,即使是使用正确的设计模式。
这是因为设计模式可能会引入更多的对象和更复杂的对象装配关系,从而使得程序有更多的动态,从局部看来变得结构复杂,难以理解并且测试困难。如果仅仅关注于形象进度,或者能够百分之百地确定需求没有变化,那么设计模式并不是很好的选择。
然而,如果从整个项目和生命周期来看,合理地使用设计模式可以使程序结构更为健壮,更具有可维护性。千万不要相信需求不会发生变化,也不要相信两周后即可完成开发。很多项目表面上早就完成,可是离开了开发人员,业务则无法进行。于是,打着维护的旗号,一直在修修补补。如果你想真正摆脱用户的纠缠,那么在设计时就不要吝啬时间和精力,健壮的结构往往会使项目能更快(从整个周期来看)完成。
3.不是万能的
设计模式的使用时自然而然的事情,很多情况下不使用设计模式是因为不需要,问题还没有复杂到非用不可的程度。我们是为了设计而使用设计模式,而不是为了使用设计模式而设计。
当你的项目发现有如下问题之一时,就需要考虑重构代码,可能会有某种模式适合。
(1)代码无法进行单元测试时;
(2)需求的变动总是导致代码的变动;
(3)由重复代码存在;
(4)继承层次过多;
(5)隐藏的以来过多;
相关文章推荐
- 设计模式不能做什么
- JAVA设计模式是个什么玩意儿_00_工厂模式家族准备篇_简单工厂模式
- 基本上,把switch,用设计模式代替,肯定是bug和过度设计。想想,本来修改一个文件几行代码可以解决的问题,变成修改3-6个类才能实现一样的功能。不是傻是什么?
- Web2.0是什么:下一代软件的业务模式与设计模式
- 什么是MVC开发模式?JavaBean的设计规范有哪些?
- 什么是设计模式?(Design pattern)--和生活结合更好理解
- [笔记丶设计模式]1. 设计模式有什么?设计模式简介
- 设计模式之 概览(设计模式是什么 设计模式分类)
- [整理,编辑] 什么是设计模式?
- 商业模式与产品设计有什么关系?以媒体公司为例
- 小菜编程成长记(十四 设计模式不能戏说!设计模式怎就不能戏说?)
- 什么是设计模式-我看GOF
- 设计模式学习心得1---什么是设计模式(design pattern)
- 设计模式什么的哪有那么神秘 ----第一集 一些吐槽和重构的韵味
- 设计模式01-什么是设计模式
- 设计模式什么的哪有那么神秘 ----第三集 创建延后
- Java设计模式之什么是设计模式
- 解读设计模式----简单工厂模式(SimpleFactory Pattern),你要什么我就给你什么
- 什么是设计模式?为什么要使用设计模式?有什么好处?
- 设计模式学习笔记二十三:今天学什么 - 桥接模式