就他吧-9ta8为您提供:身份证查询、15位转16位身份证,手机号码归属地查询,IP地址查询服务,城市天气预报查询,列车时刻表简易快速查询等等查询服务,就他吧欢迎您的光临!!
随笔- 96  评论- 750  文章- 16 

设计模式不能做什么

        GOF指出了设计模式能够解决的问题,但是设计模式也不是万能,什么都可以做,肯定有他不能做的事情或者是用了设计模式却适得其反。
1.设计模式不是法则
         模式理论的精髓之一就是模式的使用是有前提和代价的,模式是在某种前提下,综合各方面的因素考虑得出的结果。即在使用模式时总要付出一定的代价的,当然这种代价是可以接受的。如果某个模式在所有场合的使用都是必然的,那么它就不叫设计模式了,而是必须遵守的法则。例如“面向借口,而非实现编程”是法则而非模式。
         模式实际上是某种语境下的解决方案。在实际的项目中,是否采用模式取决于项目是否符合模式的语境,并且是否可以接受使用模式多带来的代价。很多情况下,模式的选择不是必然的。有时可以不采用模式也可以很好地解决问题:有时可以采用一种模式代替另一种模式,或者说在特定的语境下模式的使用不是唯一的。例如命令模式将行为抽象为类,模式的实现比较简单,也容易理解。那么这个模式是否可以在所有场合使用呢?显然不可以。如果我们把所有类的方法都抽象为命令模式,这样程序是最灵活的。因为可以动态地增加行为,但代价是程序中各个类就不再具有业务含义。业务含义全部隐藏在命令对象中,这样做的结果是晦涩难懂,可维护性降低。

2.不能提高开发速度或者形象开发速度
         如果一个开发周期作为考核标准,恐怕没有人会使用设计模式,设计模式并不能提高目前的开发速度,至少其关注的目标并不是开发速度,很多情况下甚至会降低开发速度,即使是使用正确的设计模式。
         这是因为设计模式可能会引入更多的对象和更复杂的对象装配关系,从而使得程序有更多的动态,从局部看来变得结构复杂,难以理解并且测试困难。如果仅仅关注于形象进度,或者能够百分之百地确定需求没有变化,那么设计模式并不是很好的选择。
          然而,如果从整个项目和生命周期来看,合理地使用设计模式可以使程序结构更为健壮,更具有可维护性。千万不要相信需求不会发生变化,也不要相信两周后即可完成开发。很多项目表面上早就完成,可是离开了开发人员,业务则无法进行。于是,打着维护的旗号,一直在修修补补。如果你想真正摆脱用户的纠缠,那么在设计时就不要吝啬时间和精力,健壮的结构往往会使项目能更快(从整个周期来看)完成。

3.不是万能的
         设计模式的使用时自然而然的事情,很多情况下不使用设计模式是因为不需要,问题还没有复杂到非用不可的程度。我们是为了设计而使用设计模式,而不是为了使用设计模式而设计。
          当你的项目发现有如下问题之一时,就需要考虑重构代码,可能会有某种模式适合。
(1)代码无法进行单元测试时;
(2)需求的变动总是导致代码的变动;
(3)由重复代码存在;
(4)继承层次过多;
(5)隐藏的以来过多;
posted on 2005-08-01 13:17  振河  阅读(2272)  评论(5编辑  收藏

  就他吧-9ta8伴您开心每一天