Command模式

是设计模式中最简单的模式，该接口标准实现只有一个方法。该模式常见用法是创建和执行事务。

Active Object模式

是使用Command模式的地方之一。该模式是实现多线程控制的一项最古老的技术。

TEMPLATE METHOD 模式

泛型，也就是这个模式，是可以基于泛型的。

我们往往会有一些算法，比如排序算法。它的算法部分，我可以把它放在一个基类里面，这样具体类型的比较可以放在子类里面。

敏捷开发的原则，就是不一定要使用设计模式，看情况，看需要。所以这里可以说这个BubbleSorter有些多余，直接GenericBubbleSorter使用，并实现排序算法就可以，视具体情况而定。

但是有时候，我们希望把排序算法和具体的使用者隔离开来，或者说我希望修改排序算法，但不修改其他的代码，这样耦合就降低了。

把通用算法必须要调用的抽象方法定义在一个名为IApplication的接口中。从这个接口派生出ftocStrategy，并把它传给ApplicationRunner。之后，ApplicationRunner就可以把具体工作交给这个接口去完成。

STRATEGY模式

显而易见，这个结构要优于TEMPLATE METHOD模式的结构，使用代价也高一些。STRATEGY模式比TEMPLATE METHOD模式设计更多数量的类和间接层次。ApplicationRunner中委托指针的使用招致了比继承稍微多一点的运行时间和数据空间开销。但是另一方面，如果有许多不同的应用程序要运行它，就可以重用ApplicationRunner实例，并把许多不同的Application实现传递给它，从而减小了通用算法和该算法所控制的具体细节之间的耦合。

　　TEMPLATE METHOD模式实现和使用起来都比较简单，但是不灵活。STRATEGY模式非常灵活但是必须得多创建一个类、多实例化一个对象并把这个额外的对象配置到系统中。因此对于TEMPLATE METHOD和STRATEGY模式的选择，要看是需要STRATEGY模式的灵活性还是需要TEMPLATE METHOD模式的简单性。.

FACADE模式

Db类使得Application类不需要了解System.Data命名空间中的内部细节。它把System.Data的所有通用性和复杂性隐藏在一个非常简单且特定的接口后面。

　　像Db这样的FACADE类对System.Data的使用施加了许多规约。它知道如何初始化和关闭数据库连接。它知道如何将ProductData的成员变量转换成数据库字段，或反之。它知道如何去构建合适的查询和命令去操纵数据库。它对用户隐藏了所有的复杂性。在Application看来，System.Data是不存在的，它隐藏在FACADE后面。

　　使用FACADE模式意味着开发人员已经接受了所有数据库调用都要通过Db类的约定。如果Application的任意一部分代码越过该FACADE直接去访问System.Data，那么就违反了该约定。像这样，该FACADE对Application施加了它的规约。基于约定，Db类称为了System.Data的唯一代理。

　　可以使用FACADE对程序的任何部分进行隐藏。不过，最常见的做法是使用FACADE来隐藏数据库，因此该模式也称为TABLE DATA GATEWAY。

MEDIATOR模式

　　MEDIATOR模式同样也是施加规约。不过，FACADE模式是以可见且强制的方式施加它的规约，而MEDIATOR模式则是以隐藏切自由的方式来施加它的规约的。

如果规约涉及的范围广泛并且可见，那么可以使用FACADE模式从上施加规约。另一方面，如果规约设计的范围较小并且可以自由定制，那么MEDIATOR模式是更好的选择。FACADE模式通常是约定的关注点。每个人都同意去使用该FACADE而不是隐藏于其下的对象。另一方面，MEDIATOR则对用户是隐藏的。它的规约是既成事实而不是一项约定事务。

很多时候，我们需要一些特殊的类，这些类因为资源等原因而只能有一个实例，实现这样目的的方式可能有很多，而这里要说的两个模式，通过其表达方式的有效性，能给我们带来很好的“代价/收益”平衡。 记得在Robert Martin的经典作品：敏捷软件开发-原则、模式与实践 中，这两个模式也是被单独提出来的。

Singleton 模式

       这个大概是学习设计模式时最先能够掌握和应用的一个模式，中文也常称为单件模式，其设计虽然简单，却具有很强的表达力。像我们在连接数据库时，不希望每次都打开一个新的连接，这个时候就可以用Singleton来设计这个连接，每次都通过Singleton来得到一个相同的连接（当然，singleton也可以扩展为提供n个实例，这就相当于一个连接池了）。

       Singleton的实现很简单，其提供一个公有的静态方法去访问Singleton实例，而将构造函数用private屏蔽，

Monostate模式

       singleton非常好的完成了对单个实例的限制，但是使用如Singleton.getInstance()这样的方法时，使用者就知道这是个单件，也就是说singleton对于客户（这里的客户是指使用singleton的代码）来说是不透明的。而monostate的表现恰恰和singleton相反，其对于不同的实例，使用起来却像同一个对象。

       如何实现这样的效果呢，singleton中构造函数是私有的（private），monostate因为要创建不同实例，构造函数必须是public，我们只需再将getInstance从静态函数变为非静态的即可。

NULL OBJECT模式

大多数人曾经由于忘记对null进行检查而受挫。该管用手法虽然常见，但却是丑陋且易出错的。

　　通过让Db.GetEmployee抛出一个异常而不是返回null，可以减少出错的可能性。不过，try/catch块对比null的检查更加丑陋。

　　可以使用NULL OBJECT模式来解决这些问题。通常，该模式会消除对null进行检查的需要，并且有助于简化代码。

那些长期使用基于C语言的人已经习惯与函数对于某种失败返回null或者0。我们认为对这样的函数的返回值是需要测试的。NULL OBJECT模式改变了这一点。使用该模式，我们可以确保函数总是返回有效的对象，及时在它们失败时也是如此。这些代表失败的对象“什么也不做”。