哪些设计模式最值得学习-技术开发it知识库-Ubuntu系统_Ubuntu服务器

　　最近又在首页看到几篇设计模式相关的学习随笔。回想起来，这几年在园子里发布的有关设计模式的随笔都有一个共同的特点。那就是Factory和Singleton居多，如果是系列的，也往往是从这两个模式开始的。由于能够坚持把《设计模式》中所有模式都写完的非常少，所以基本上也很少见到有关其它模式的随笔。

　　这种情况也很好理解，因为《设计模式》这本书就是按照这个顺序来的。最先讲述的就是Abstract Factory模式，于是它排第一也无可厚非；排第二的Builder基本不太容易见到；第三的Factory Method由于也叫“Factory”所以往往和Abstract Factory放在一起，或者干脆就混淆了；第四的Prototype也不是太容易见到；第五位的Singleton简单易懂，易学易用。而再往后的模式，恐怕作者们就没什么耐心学下去了……这可能就是为什么Factory和Singleton出现频率如此之多的原因吧。

　　《设计模式》已经出版超过15年了，到今天已经不是什么新鲜的东西了，可以说正在由“绝招”慢慢向着“基本功”转变着。然而，这种学习模式的方式方法却实在令人担忧。

　　Abstract Factory在实际中并不常见，因为它需要你有两套并行的继承体系，需要对同一个抽象有多于一种的实现方式。这种复杂的系统可以说不是每个领域，每个开发人员都能遇到的。在某些特定的领域可能很常见，但是在大多数领域并不需要这么复杂的对象创建方法。这就造成了很多人“杀鸡用宰牛刀”，用复杂的方式，解决不那么复杂的问题。后果是增加了不必要的复杂度，给系统维护增加了困难。

　　另一个模式Singleton，由于实现简单，意图“似乎”也很明显。被很多人用来作为“优化”的一种方式。通过这种方式来节省内存空间，减少对象实例。但是单一实例本身就等同于全局变量，而全局变量在几十年前就已经被证明是“反模式”了，用另一种形态的全局变量来代替另一种形态的全局变量有什么好处么？问题在与，Singleton的“意图”并不在于优化，而是在于“妥协”。Singleton的目的在于保证对象有单一的实例，这是因为对象必须要有单一的实例，如果存在多个实例，可能会引发错误。也就是说，Singleton以牺牲程序的清晰和可维护性，来达到保证程序正确的目的。这跟本就和优化八竿子打不着，这完全是一种设计上的妥协，牺牲一些好处来获取更大的好处。如果仅仅是为了节省几个对象实例，而非程序的正确才使用Singleton，那就是丢了西瓜拣芝麻。况且节省那几个实例也跟本就不可能对程序的性能有太大的影响（特殊领域除外）。

　　人的时间是有限的，23个模式也不是都那么常用，哪些模式才是最经常用到的，才是最值得学习的呢？

　　第一梯队：Iterator，Observer，Template Method，Strategy

　　Iterator：LINQ，foreach这不都是Iterator么。

　　Observer：MVC的核心，.NET中事件就是Observer。

　　Strategy：对同一个行为有不同实现的时候，如果考虑将行为的实现委托（不是.NET中的委托）给另一个类，那就用到了Strategy。通过这种方式，可以简单的替换算法的实现类，来达到更换算法的目的。

class Foo
{
  private IBar bar;
  public Foo(IBar bar)
  {
    this.bar = bar;
  }

  public void DoSomething()
  {
    //some code
    bar.DoWhatYouWant();
    //some code
  }
}

class A : IBar
{
  public void DoWhatYouWant()
  {
    //do in A's way
  }
}
class B : IBar
{
  public void DoWhatYouWant()
  {
    //do in B's way
  }
}        
        
        
        
      
        it知识库：哪些设计模式最值得学习，转载需保留来源！
        郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。

相关文章阅读