哪些设计模式最值得学习

　　最近又在首页看到几篇设计模式相关的学习随笔。回想起来，这几年在园子里发布的有关设计模式的随笔都有一个共同的特点。那就是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
  }
}

class Foo
{
  public void DoSomething()
  {
    //some code
    DoWhatYouWant();
    //some code
  }
  protected abstract void DoWhatYouWant();
}

class A: Foo
{
  protected override void DoWhatYouWant();
  {
    //do in A's way
  }
}

class B: Foo
{
  protected override void DoWhatYouWant();
  {
    //do in B's way
  }
}

　　第二梯队：Adapter，Facade，Decorator

　　Adapter：当你需要使用第三方库，但是又不想太依赖于它的API，以便于今后在需要时可以方便的切换到另一个库的时候，你就需要在你的代码和第三方API之间放置一个抽象层，也就需要用Adapter模式了。比如你想使用log4net，如果直接在代码中到处引用log4net的API，将来有一天需要切换到另一个库比如EntLib，你的改动量可就大了去了。如果在一开始就自己设计一个API，在代码中使用自己的API，再用Adapter模式将log4net的API包装到自己的API中，如果有一天想要切换到Entlib，只要为EntLib在写一个Adapter就行了。对于IoC框架也是一样的。不过需要注意的是，如果第三方库的API接口非常庞大，使用Adapter就会很麻烦，因为你需要包装太多的东西，那么使用Adapter可能就不是一个太好的主意。或许谨慎考虑确定一个不太可能会变化的第三方库更好一些。

　　Facade：基本上用于简化API，隐藏细节，在一个系统中，高层模块调用低层模块时，如果低层模块API比较复杂，而高层模块并不需要这种复杂度，那么加一个Facade，可以简化高层模块使用API的难度。

　　Decorator：为一个类的行为增加行为，比如ASP.NET MVC中的Action Filter。

　　第三梯队：Command，State，Composite

　　Command：统一接口，Undo/Redo。

　　State：当你的model有多种状态，model的行为在每种状态下并不一样的时候，就需要用State。如果你有多个相似的　　Switch，那也可能意味着需要用State来代替Switch。

　　Composite：ASP.NET WebForm的Page和Control就是一个例子。

　　这些模式和分类只是凭我的感觉，并没有任何实际的数据做支持，而我的感觉也只来源于我所接触到的领域和代码。 希望同学们也可以提供自己接触到的代码中，最常见到和用到的模式。