设计模式学习总结

      这两天在看Broadview的.NET与设计模式一书。发现这本书的观点很有道理，虽然今天刚把Singtelon模式做了一个总结，但是从学习设计模式的路上往回倒一步，先写一个学习设计模式应该注意的地方。
      我觉得要注意的主要有以下几点：
      1.不要把设计模式当作解决方案，尽管GoF的设计模式中更加偏重于解决方案。正是因为很多人把设计模式局限在解决方案这个概念内，所以才导致设计模式的滥用和设计过度。
      2.先提一个概念，什么叫设计模式的应用场景呢？在这里我们可以认为是已经设计完成的类和接口之间的关系。只有在相关上下文和各种关切完全符合时，设计模式中的解决方案才是最优的。所以在使用设计模式之前，一定要认真分析问题所处的场景，看是否和设计模式的使用场合相符。如果不是很相符的话，那么这个设计模式尽管也可能可以解决这个问题，但是很可能导致系统复杂，后期测试困难等问题。
      3.设计模式的精髓之一是将可变部分封装为对象，带来的好处是系统更加灵活，易于维护，但是也增加了大量对象。所以在应用某个设计模式之前这个也是我们需要考虑的。如果增加的对象超出了我们可以控制的范围，那么好的，放弃这个设计模式的使用。
      4.设计模式不能提高开发速度或者说是形象开发速度。在很多情况下即使我们选择了正确的设计模式也会是我们开发的速度降低，但是这个降低是相对的。从整个项目的生命周期来看，合理的使用设计模式可以让我们的程序结构更加健壮，更低的耦合和更高的内聚。其实这样的话，看起来我们的开始进度慢了，实际上很多在测试和维护阶段会遇到的问题已经在开发阶段被我们避免了。
      5.设计模式不是万能的。这是我们必须承认的，不管任何一种东西都不是万能的。就像面向对象三大特性的继承特性，虽然这是一个很好的特性，但是如果类之间继承的层次太深，那么最底层的子类肯定是十分庞大的。所以我们有时候说组合是比继承更好的设计方法。在设计模式中，我们要注意当你的项目遇到以下问题时候，就需要考虑代码重构：
      （1）：代码的后期单元测试很麻烦，这里可能就是因为设计模式的应用导致对象过于多导致的。
      （2）：代码有大量重复。
      （3）：如果需求的变动总是导致很多代码的变动，那么你这个设计模式的使用肯定是失败的，或许说失败太打击人了可以用不成功来敷衍下自己。但是在这个时候你一定要注意了。因为设计模式的目的就是程序结构的健壮，项目构架的更加合理，但你的系统因为需求的变动总是在改变代码，那么好了你可以考虑换个设计模式或者干脆就别用了。在这里我们还可以再提下我们上面提到的，在使用设计模式的时候一定要注意语境。
      （4）：隐藏的依赖过多。在这里肯定导致系统过于复杂了。后期的测试你会发现你要疯掉了。
      （5）：继承的层次太多。肯定是不行的，越来越庞大的子类。
      上面是自己好久的理解，虽然设计模式的23中只是看了一点。因为设计模式这个课题自己很早就想看，只是那时候忙于ACM实在是没时间啊，接下好好学习下设计模式。突然想到一句话，设计模式之于面向对象程序设计就像数据结构之于结构化的程序设计。前写结构话的代码太多了，要慢慢改过来啊。
      想了好多，这估计是自己写的最长的一篇自己一字一字敲上去的随笔，如果大家看到有什么错误希望指出来，大家一起学习...