模式第一辑：Interface Pattern上(By Ryan)
前段时间准备将设计模式逐个的进行总结，可是仔细想了想，其实有不少设计模式大家一直在用，二来只是写些套用了模式的代码上来也没有很多特别之处，所以这里只是将设计模式稍作总结。
Facade Pattern其实就是避免开发者陷入到代码Burden，始终做重复性工作。比如读文件时不断的打开一个Stream，不断的新建新的Writer，还得别忘了关闭它们，而Facade模式可以使得你可以建造一个Facade Tier，然后利用Facade"直白"的语言去编程，比如当你想写一段文字到文本中时只需要调用“写一句”方法，而不需要关心如何打开Stream，如何创建Writer；又或者更加常见的，公司里的Library里一般都有处理Sql的类，我们可以避免了解Ado.net的细节，就可以“告诉”Facade Tier去捞取数据或更新资料。很直白，告诉它去处理怎样的事情就行，不必关心细节。如果你的方法的名称设计合理的话可以很容易的知道你写的代码什么意思.
在.net FCL中没有什么Facade Pattern的例子,这是因为如果都提供类似这样的Utility,那么编程也就失去了乐趣和自由了，但是在Enterprise Library中，处理的Sql的类型就符合了Facade Pattern，例如SqlDatabase，对Enterprise Library感兴趣的话可以看看。
至于Adapter模式，当我们已经存在一些可以实现功能的类，但是还需要进行一些改造，它们才能满足我们的需求，为我们所用。如类图中所示，需要实现可记忆的画图类，需要用到现有的Graphic类,而又需要实现新的功能,这是有两种选择,第一就是通过继承实现,当然这需要在很熟悉这个类的构造的情况下实现.而另外一种实现方式则简单很多,只需要会使用这个现有Graphic类,就可以得到实现.
当然往往模式只是一些我们编程需要有的一些观念罢了,生搬硬套反而不讨好.自由的使用模式才是王道,比如使用Facade Pattern做Sql的类库时,可能我们就需要想到使用Factory Method,这样可以做少量的调整就可以实现多种数据库Connection对象的创建.
Facade Pattern其实就是避免开发者陷入到代码Burden，始终做重复性工作。比如读文件时不断的打开一个Stream，不断的新建新的Writer，还得别忘了关闭它们，而Facade模式可以使得你可以建造一个Facade Tier，然后利用Facade"直白"的语言去编程，比如当你想写一段文字到文本中时只需要调用“写一句”方法，而不需要关心如何打开Stream，如何创建Writer；又或者更加常见的，公司里的Library里一般都有处理Sql的类，我们可以避免了解Ado.net的细节，就可以“告诉”Facade Tier去捞取数据或更新资料。很直白，告诉它去处理怎样的事情就行，不必关心细节。如果你的方法的名称设计合理的话可以很容易的知道你写的代码什么意思.
在.net FCL中没有什么Facade Pattern的例子,这是因为如果都提供类似这样的Utility,那么编程也就失去了乐趣和自由了，但是在Enterprise Library中，处理的Sql的类型就符合了Facade Pattern，例如SqlDatabase，对Enterprise Library感兴趣的话可以看看。
至于Adapter模式，当我们已经存在一些可以实现功能的类，但是还需要进行一些改造，它们才能满足我们的需求，为我们所用。如类图中所示，需要实现可记忆的画图类，需要用到现有的Graphic类,而又需要实现新的功能,这是有两种选择,第一就是通过继承实现,当然这需要在很熟悉这个类的构造的情况下实现.而另外一种实现方式则简单很多,只需要会使用这个现有Graphic类,就可以得到实现.
当然往往模式只是一些我们编程需要有的一些观念罢了,生搬硬套反而不讨好.自由的使用模式才是王道,比如使用Facade Pattern做Sql的类库时,可能我们就需要想到使用Factory Method,这样可以做少量的调整就可以实现多种数据库Connection对象的创建.
