大话设计模式笔记（二十一、二十二、二十三、二十四、二十五、二十六）

二十一、单例模式（Singleton）

定义：保证一个类仅有一个实例，并提供一个访问它的全局访问点。

1、通常我们可以让一个全局变量使得一个对象被访问，但它不能防止你实例化多个对象。一个最好的办法就是，让类自身负责保存它的唯一实例。这个类可以保证没有其他的实例可以被创建，并且它可以提供一个访问该实例的方法。

2、注意在多线程时，如果不加锁，会有可能造成创建多个实例的，需要lock，lock是确保当一个线程位于代码的临界区时，另一个线程不进入临界区。如果其他线程试图进入锁定的代码，则它将一直等待，直到该对象被释放。

二十二、桥接模式（Bridge）

定义：将抽象部分与它的实现部分分离，使他们都可以独立的变化。

个人感悟：在思考具体业务时，应优先考虑组合、聚合等松耦合的关系，因为大部分业务特别是较为复杂的业务肯定不可能用继承等强耦合来表达，可以通过组合聚合来搭建业务需求，在细节部分用继承的强耦合实现。记住不能盲目使用继承，继承是一种强耦合关系，父类变化子类也要必须变化，丧失了灵活性，继承是一种is-a的关系。我感觉桥接模式不仅仅是代码设计模式，其实就是组织代码的思维逻辑，当然设计模式就是设计的模式，就是组织代码的模式，就是如何根据具体业务的需求来组织代码，从而达到优雅的目的。

1、设计原则：合成、聚合复用原则，即优先使用对象合成、聚合，而不是类继承

2、聚合表示一种弱的拥有关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分；合成则是一种强的拥有关系，体现了严格的部分和整体的关系，部分和整体的生命周期是一样的。

3、优先使用对象的合成、聚合将有助于你保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长为不可控的庞然大物。

4、什么叫抽象与它的实现分离？并不是说让抽象类与其派生类分离，因为这没有任何意义。实现指的是抽象类和它派生类用来实现自己的对象。

5、实现系统可能有多角度分类，每一种分类都可能有变化，那么把这种多角度分离出来让他们独立变化，减少他们之间的耦合

6、在发现我们需要多角度去分离实现对象，而只用继承会造成大量的类增加，不能满足开发-封闭原则时，就应该考虑用桥接模式。

7、只要真正深入的理解了设计原则，很多设计模式其实就是原则的应用而已，或许在不知不觉中就使用设计模式了

二十三、命令模式（Command）

定义：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。

优点：1、较容易地设计一个命令队列 2、在需要的情况下，可以较容易地将命令记入日志 3、允许接收请求的一方决定是否否决请求 4、可以容易地实现对请求的撤销和重做 5、由于加进新的具体命令类不影响其他的类，因此增加新的具体命令类很容易。最关键的优点是命令模式把请求一个操作的对象与知道怎么执行一个操作的对象分割开。

1、敏捷开发的原则告诉我们，不要为代码添加基于猜测的、实际不需要的功能，如果不清楚一个系统是否需要命令模式，一般就不要急着去实现它。

二十四、责任链模式（Chain of Responsibility）

定义：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系，将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理为止。

特点：当客户提交一个请求时，请求是沿链传递直至有一个ConcreteHandler对象负责处理它，这样做的好处是请求者不用管哪个对象来处理，这使得接受者和发送者都没有对方的明确信息，且链中的对象自己也并不知道链的结构。

感悟：其实一个简单的请求会直接在一个类中处理，如果请求的的处理业务很复杂，涉及多种可能，例如本书的例子，客户请求假期，处理请求涉及到上级、高层、boss，如果在一个类中if else来处理的话，结构不清晰，用责任链来把具体业务进行分割

二十五、中介者模式（Mediator）

定义：中介者模式用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互

二十六、享元模式（Flyweight）

定义：享元模式，运用共享技术有效地支持大量细粒度的对象。