我看设计模式的六原则——设计模式（三）

        原来转载了一篇关于设计模式原则的总结，虽然感觉他写的很高大上，但是还是没有自己来一遍对于知识的理解深刻所以就再写一篇关于设计模式原则的总结。

开放——封闭原则(Open Closed Prinpicle)

1.定义

       软件实体（类、模块、函数等等）应该可以扩展，但是不可修改

2.理解

       开放封闭原则应该是所有面向对象的核心，为什呢？因为软件设计所追求的就是封装变化降低耦合，开放封闭模式是这一思想最直接的体现。对于扩展开放就可以使得在需求变化时，可以对现有代码进行扩展以适应新变化；对于修改关闭意味着当设计完成之后就可以独立完成工作，而不需要对类进行任何的修改。

       而我们也非常清楚，软件的需求是在不断变化的，没有一个软件可以一成不变，那么对于我们设计人员来说，如何做到不对原有修改，却可以灵活的扩展呢？这就要求我们面向抽象编程，也就是编程不依赖于具体，依赖于抽象，做到真正的开放封闭。

单一职责原则（Single Resonsibility Prinpicle）

1.定义

        就一个类而言，应该仅有一个引起变化的原因

2.理解

       上面这句话理解起来有点费劲，那么通俗的说单一职责原则就是一个类最好完成一件事。一个类围绕它自身职责的轴线去完成，应该由它完成的工作，不应该去理会其他类的工作。如果一个类具有一个以上的职责，那么它们就可能耦合在一起，当一个职责发生变化时，影响另外的职责。单一职责原则做的好，就可以完成我们软件设计高内聚，低耦合的追求。利于软件的扩展和类的复用。

里氏代换原则（Liskov Substitution Prinpicle）

1.定义

       子类型必须能够替换掉它们的父类型。

2.理解

       里氏代换原则是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

依赖倒转原则（Dependence Inversion Prinpicle）

1.定义

A.高层模块不应该依赖底层模块，两个都应该依赖抽象。

B.抽象不应该依赖细节。细节应该依赖抽象。

2.理解

面向抽象编程，就是面向接口编程。接口这个东西嘛，我认为就是模块和模块之间起到连接的地方。比方说用计算机和音响来放音乐，音响是音响类，计算机作为计算机类，通信的地方就是USB接口，只要计算机留出接口那么，无论是什么音响都可以来用（即使不是音响也可以用）。

迪米特法则（Law Of Demeter）

1.定义

       如果两个类不必直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某个方法的话，可以通过第三者转发这个调用。

2.理解

       迪米特法则的目的是为了降低类之间的耦合性，每个类尽量的减少对其他类的依赖，它强调了类之间的松耦合。类之间的耦合越弱，越有利于复用，一个处在松耦合的类别修改，不会对有关的列造成波及。但是正如成也萧何败萧何一样，它的优点恰恰也是它存在缺陷的地方，如果迪米特法则应用过多，可能造成一种现象就是，系统中存在很多这样的类，它的存在仅仅是为了传递类之间的相互调用关系，这在一定程度上反而增加了系统的复杂程度。

合成/聚合复用原则（CARP）

1.定义

       尽量使用合成/聚合，尽量不要使用类继承。

2.理解

聚合：表示一种弱的“拥有”关系，体现A对象可以包含B对象，但B对象不一定是A对象的一部分；比如：每个人都属于某一个人种，但是具体到每个人，可能不在特定的种群中。

合成：表示一种严格的整体和部分的关系，就像人和自己的器官，生命周期是一样的（不要和我说器官移植，那不属于自然情况）。

为什么要用合成/聚合而不是继承呢？

      1.对象的继承关系在编译时就定义好了，所以无法在运行时改变从父类继承的子类的实现

　　2.子类的实现和它的父类有非常紧密的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化

　　3.当你复用子类的时候，如果继承下来的实现不适合解决新的问题，则父类必须重写或者被其它更适合的类所替换这种依赖关系限制了灵活性，并最终限制了复用性

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