设计模式总结

1、单一职责原则(SRP)：

　　（1）、SRP(Single Responsibilities Principle)的定义：就一个类而言，应该仅有一个引起它变化的原因。简而言之，就是功能要单一。

　　（2）、如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。(敏捷软件开发)

　　（3）、软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。

     小结：单一职责原则（SRP）可以看做是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。责任过多，引起它变化的原因就越多，这样就会导致职责依赖，大大损伤其内聚性和耦合度。

  2、开放关闭原则(OCP)

　　（1）、OCP(Open-Close Principle)的定义：就是说软件实体(类，方法等等)应该可以扩展（扩展可以理解为增加），但是不能在原来的方法或者类上修改，也可以这样说，对增加代码开放，对修改代码关闭。

　　（2）、OCP的两个特征： 对于扩展（增加）是开放的，因为它不影响原来的，这是新增加的。对于修改是封闭的，如果总是修改，逻辑会越来越复杂。

     小结：开放封闭原则（OCP）是面向对象设计的核心思想。遵循这个原则可以为我们面向对象的设计带来巨大的好处：可维护（维护成本小，做管理简单，影响最小）、可扩展（有新需求，增加就好）、可复用（不耦合，可以使用以前代码）、灵活性好（维护方便、简单）。开发人员应该仅对程序中出现频繁变化的那些部分做出抽象，但是不能过激，对应用程序中的每个部分都刻意地进行抽象同样也不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。

   3、里氏代替原则(LSP)
 
     （1）、LSP(Liskov Substitution Principle)的定义：子类型必须能够替换掉它们的父类型。更直白的说，LSP是实现面向接口编程的基础。

      小结：任何基类可以出现的地方，子类一定可以出现，所以我们可以实现面向接口编程。 LSP是继承复用的基石，只有当子类可以替换掉基类，软件的功能不受到影响时，基类才能真正被复用，而子类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

  4、依赖倒置原则（DIP）

     （1）、DIP(Dependence Inversion Principle)的定义：抽象不应该依赖细节，细节应该依赖于抽象。简单说就是，我们要针对接口编程，而不要针对实现编程。

     （2）、高层模块不应该依赖低层模块，两个都应该依赖抽象，因为抽象是稳定的。抽象不应该依赖具体（细节），具体（细节）应该依赖抽象。

      小结：依赖倒置原则其实可以说是面向对象设计的标志，如果在我们编码的时候考虑的是面向接口编程，而不是简单的功能实现，体现了抽象的稳定性，只有这样才符合面向对象的设计。

  5 接口隔离原则（ISP）

     （1）、接口隔离原则（Interface Segregation Principle, ISP）指的是使用多个专门的接口比使用单一的总接口要好。也就是说不要让一个单一的接口承担过多的职责，而应把每个职责分离到多个专门的接口中，进行接口分离。过于臃肿的接口是对接口的一种污染。

     （2）、使用多个专门的接口比使用单一的总接口要好。

     （3）、一个类对另外一个类的依赖性应当是建立在最小的接口上的。

     （4）、一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。

     （5）、“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。

       小结：接口隔离原则（ISP）告诉我们，在做接口设计的时候，要尽量设计的接口功能单一，功能单一，使它变化的因素就少，这样就更稳定，其实这体现了高内聚，低耦合的原则，这样做也避免接口的污染。

   组合复用原则（CRP）

     （1）、组合复用原则（Composite Reuse Principle, CRP）就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分。新对象通过向这些对象的委派达到复用已用功能的目的。简单地说，就是要尽量使用合成/聚合，尽量不要使用继承。

     （2）、要使用好组合复用原则，首先需要区分”Has—A”和“Is—A”的关系。 “Is—A”是指一个类是另一个类的“一种”，是属于的关系，而“Has—A”则不同，它表示某一个角色具有某一项责任。导致错误的使用继承而不是聚合的常见的原因是错误地把“Has—A”当成“Is—A”.例如：鸡是动物，这就是“Is-A”的表现，某人有一个手枪，People类型里面包含一个Gun类型，这就是“Has-A”的表现。

     小结：组合/聚合复用原则可以使系统更加灵活，类与类之间的耦合度降低，一个类的变化对其他类造成的影响相对较少，因此一般首选使用组合/聚合来实现复用；其次才考虑继承，在使用继承时，需要严格遵循里氏替换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。

   7 迪米特法则（Law of Demeter）

      （1）、迪米特法则（Law of Demeter，LoD）又叫最少知识原则（Least Knowledge Principle，LKP），指的是一个对象应当对其他对象有尽可能少的了解。也就是说，一个模块或对象应尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立，这样当一个模块修改时，影响的模块就会越少，扩展起来更加容易。

      （2）、关于迪米特法则其他的一些表述有：只与你直接的朋友们通信；不要跟“陌生人”说话。

      （3）、外观模式（Facade Pattern)和中介者模式（Mediator Pattern）就使用了迪米特法则。

       小结：迪米特法则的初衷是降低类之间的耦合，实现类型之间的高内聚，低耦合，这样可以解耦。但是凡事都有度，过分的使用迪米特原则，会产生大量这样的中介和传递类，导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。

    、工厂方法模式（Factory Method Pattern）：一种工厂生产一种产品，工厂类和产品类是一一对应的，他们是平行的等级结构，强调的是“单个对象”的变化。

       动机（Motivate）：在软件系统的构建过程中，经常面临着“某个对象”的创建工作：由于需求的变化，这个对象（的具体实现）经常面临着剧烈的变化，但是它却拥有比较稳定的接口。如何应对这种变化？如何提供一种“封装机制”来隔离出“这个易变对象”的变化，从而保持系统中“其他依赖对象的对象”不随着需求改变而改变？

       意图（Intent）：定义一个创建对象的工厂接口，由其子类决定要实例化的类，将实际创建工作推迟到子类中。

三、创建型模式

    创建型模式就是用来解决对象实例化和使用的客户端耦合的模式，可以让客户端和对象实例化都独立变化，做到相互不影响。创建型模式包括单例模式、工厂方法模式、抽象工厂模式、建造者模式和原型模式。

    、单例模式（Singleton Pattern）：解决的是实例化对象的个数的问题，该模式是把对象的数量控制为一个，该模式可以扩展，可以把实例对象扩展为N个对象，N>=2。比如对象池的实现。

       动机（Motivate）：在软件系统构建的过程中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例，才能确保它们的逻辑正确性、以及良好的效率。如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例？如果指望使用者不使用构造器来重复创建对象，这是不对的。这应该是类设计者的责任，而不是使用者的责任。

       意图（Intent）：保证一个类仅有一个实例，并提供一个该实例的全局访问点。

 建造者模式（Builder Pattern）：该模式要解决的是由多个子部分对象构成的一个复杂对象的创建的问题，该复杂对象构成算法稳定，各个子部分对象易变化的情况。强调组装过程的稳定。

抽象工厂模式（Abstract Factory Pattern）：该模式关注的是多批多系列相互依赖的产品的变化，比如：SQLConnection，SQLCommand，SqlDataReader,SqlDataAdapter，就是一批相互依赖的对象，他们变化可以产生OledbConnection,OledbCommand,OledbDataReader,OledbDataAdapter

适配器模式（Adapter Pattern）：该模式主要关注的是接口转换的问题，将匹配的接口通过适配对接工作。

享元模式（Flyweight Pattern）：该模式注重保留接口，在内部使用共享技术对对象存储进行优化

外观模式（Facade Pattern）：该模式注重简化接口，简化组件系统与外部客户程序的依赖关系，是Lod（迪米特原则，也叫：最少知识原则）原则的最好的体现，

组合模式（Composite Pattern）：该模式着重解决统一接口的问题，将“一对多”的关系转化为“一对一”的关系，让使用叶子节点和树干节点保持接口一致。

模板方法模式（Template Method Pattern）：该模式注重对算法结构的封装，定义算法骨架，并且稳定，但是支持算法子步骤的变化。

命令模式（Command Pattern）：该模式注重将请求封装为对象，通过将一组行为抽象为对象，实现行为请求者和行为实现者之间的解耦。也可以实现“撤销/重做”的功能，类似“宏”的功能实现也很容易。