《大话设计模式》部分模式总结（三）

17.单例模式：

对于一些刚刚学习面向对象思想的小菜们，普遍的会出现定义过多的类这一现象，对此，程杰老师提出，有些类，也需要计划生育。也就是说，类，并不是越多越好。这就涉及到了一个模式——单例模式。
单例模式，保证一个类仅有一个实例，并提供一个访问它的全局访问点。通常我们可以让一个全局变量使得一个对象被访问，但它不能防止你实例化多个对象。一个最好的办法就是，让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建，并且它可以提供一个访问该实例的方法。
此时需要注意的就是在多线程程序中，使用单例模式可能会造成创建多个实例。这时候我们就可以给进程加一把锁来处理。当然了，我们不能让线程每次都加锁，而只是在实例未被创建的时候再加锁处理，同时也能保证线程
的安全。这种做法被称为：多重锁定。

18.桥接模式：

首先先说一个原则——合成/聚合复用原则，即优先使用对象合成/聚合，而不是类继承。它的好处是，有助于保持每个类被封装，并被集中在单个任务上。这样类和类的继承层次会保持较小的规模，并且不太可能增长为不可控制的庞然大物。
对此涉及到的设计模式就是桥接模式。桥接模式将抽象部分与它的实现部分分离，使它们都可以独立的变化。其中，抽象与实现相分离，也就是实现系统可能有多角度分类，每一种分类都有可能变化，那么就把这种多角度分离出来让它们独立变化，减少它们之间的耦合。

19.命令模式：

饭店就餐人数众多时，服务员该如何记清所有菜单呢？这就类似了命令模式。将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可撤销的操作。
它的优点，第一是能较容易地设计一个命令队列，第二，在需要的情况下，可以较容易地将命令记入日志，第三，允许接受请求的一方决定是否要否决请求；第四，实现对请求的撤销和重做；第五就是对加进类的具体命令类不影响其他的类，因此增加新的具体命令类很容易。

20.职责链模式：

员工的加薪请求，历经了经理，人力资源总监和总经理三个人，涉及此问题的模式就是——职责链模式。
职责链模式：使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，知道有一个对象处理它为止。
在职责链模式中，接受者和发送者都没有对方的明确信息，且链中的对象自己也并不知道链的结构。结果是职责链可简化对象的相互连接，他们仅需保持一个指向其后继者的引用，而不需保持它所有的候选接受者的引用，大大降低了耦合度。

21.中介者模式：

联合国对世界和平的贡献不可估量，在其中，联合国就起到了中介者，也可以说是调停者的作用。
中介者模式，用一个中介对象来封装一系列的对象交互。中介者使各个对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
中介者模式一般应用于一组对象以定义良好但是复杂的方式进行通信的场合。

22.享元模式：

如果要做三个产品展示的网站，其中它们本质的代码都是一样的，为了节约服务器的资源，我们可以使用享元模式。
享元模式，运用共享技术有效地支持大量细粒度的对象。享元模式可以避免大量非常相似类的开销。
如果一个应用程序使用了大量的对象，而大量的这些对象造成了很大的存储开销时就应该考虑使用享元模式；还有就是对象的大多数状态可以外部状态，如果删除对象的外部状态，那么可以用相对较少的共享对象取代很对组对象，此时也可以考虑使用享元模式。

23.解释器模式：

管理者的话语总是前回路转，我们是否能听懂他的弦外之音呢？这时候就谈到了解释器模式。给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
解释器模式需要解决的是，如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。

24.访问者模式：

访问者模式表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
它把数据结构和作用于结构上的操作之间的耦合解脱开，是的操作集合可以相对自由地演化。访问者模式的目的就是把处理从数据结构分离出来。
访问者模式对于增加新的操作很容易，因为增加新的操作就意味着增加一个新的访问者。访问者模式将有关的行为集中到一个访问者对象中。

至此，24种设计模式总结完毕，希望会对您有所帮助！