单一职责原则－SRP－Single responsibility principle

    就一个类而言，应该只有一个导致其变化的原因。一个职责就是一个变化的轴线，一个类如果承担的职责过多，就等于将这些职责耦合在一起。一个职责的变化可能影响到其他职责。

        什么是职责？

            职责是“变化的原因”

                例如某一个类现在同时具有“连接”和“通信”两种职责，根据单一职责原则，则可能存在两种处理方式：

                    1：“连接”和“通信”可能独立变化时

                        这种情况下，应该把职责分开。例如，应用的变化导致“连接”部分方法的签名（signature）发生了变化，那么使用数据“连接”的部分也需要重新编译，部署，这会相当麻烦，使得设计僵化。

                    2:“连接”和“通信”同时变化时

                        这种情况下，不必将职责分开。反而分离可能导致“不必要的复杂性”。

 

开放封闭原则－OCP－Open-Closed Principle

    软件实体（类、模块、函数等）应该是可以扩展的，同时还可以是不必修改的，更确切地说，函数实体应该：

        1：对扩展是开放的

            当应用的需求变化时，我们可以对模块进行扩展，使其具有满足改变的新的行为－－即我们可以改变模块的功能。

        2：对更改是封闭的

            对模块进行扩展时，不必改动已有的源代码或二进制代码。

    如果任何修改都需要改变已经存在的代码，那么可能导致牵一发动全身现象。

    事实上没有对所有变化的情况都封闭的模型，我们可以预测它们，或则直到我们发现他们才行动。

    如下面的示例：

       

    class ClentInterface{

        virtual void ServerFunc() = 0;

    };

 

    class server:public ClientInterface {

        int serverData;

    public

        void ServerFunc();

    }

 

    Class client{

        ClientInterface& ci;

    public

        client(ClientInterface &CI):ci(CI){

        }

        void useServer(){

            ci.ServerFunc();

        }

    };

    一个问题： 为什么上述的ClientInterface这个类要取这个名字，叫做AbstractServer岂不更好？

    其实这里面蕴含了一个思想：

        client类中更多的描述了高层的策略，而Server类中对这些策略的一种具体实现。而接口是策略的的一个组成部分，他跟client端的关系更加密切

    我们可以这样想问题；ClientInterface中定义了client期望Server做什么，而server具体类是对client这种要求的一种具体实现。

    OCP原则其实是要求我们清晰的区分策略和策略的具体实现形式。允许扩展具体的实现形式（开放），同时将这种扩展与策略隔离开来，使其对上层的策略透明（封闭）。

    一般情况下，无论模块多么“封闭”，都会存在一些无法对之封闭的变化，没有对所有变化的情况都封闭的模型

 

接口隔离原则－ISP－Interface Segregation Principle

    不应该强迫客户依赖于他们不用的方法

    一个类的不内聚的“胖接口”应该被分解成多组方法，每一组方法都服务于一组不同的客户程序。

 

依赖倒置原则－DIP－Dependency Inversion Principle

    高层模块不应该依赖于底层模块。二则应该依赖于抽象。抽象不应该依赖于细节。细节应该依赖于抽象。

    所谓“倒置”是相对于传统的开发方法（如结构化开发方法）中总是倾向于让高层模块依赖于底层模块而言的。

    高层包含应用程序的策略和业务模型，而底层包含更多的实现细节，平台相关细节等。高层依赖底层将导致：

        难以复用：底层改变一个软硬件平台将导致一些具体的实现发生变化，如果高层依赖底层，这种变化将导致逐层的更改。

        难以维护：底层通常是易变的。

    良好的OO体系结构都具有清晰的层次定义，每个层次通过一个定义良好的、受控的接口向外提供了一组内聚的服务。

    依赖关系倒置：下层的实现，依赖于上层的接口。

    接口所有权倒置：客户拥有接口，而服务者则从这些接口派生。

    依赖不倒置的开发

        自顶向下首先设计整个软件的分解结构

        然后首先实现下层的功能

        再实现上层的功能，并使上层调用下层函数

    依赖倒置的开发

        首先设计上层需要调用的接口，并实现上层

        然后底层类从上层接口派生，实现底层

    接口属于上层

 

LisKov替换原则－LSP－Liskov Substitution Principle

    子类型Subtype必须能够替换他们的基类型（Basetype），若对每个类型S的对象O1，都存在一个类型T的对象O2，使得所有针对T编写的程序P中，用O1替换O2后，程序P的行为功能不变，则S是T的子类型。

 

 

依赖倒置原则（DIP）：Dependency Inversion Principle

    dependency |dɪˈpendənsi| noun 依赖

    inversion |ɪnˈvɜːʃn, American ɪnˈvɜːrʒn| noun 倒转 颠倒

    principle |ˈprɪnsəpl| noun 原则

 

LisKov替换原则（LSP）：Liskov Substitution Principle

    substitution |ˌsʌbstɪˈtjuːʃn, American -ˈtuː-| noun 代替 替换

 

单一职责原则（SRP）：Single responsibility principle

    responsibility |rɪˌspɒnsəˈbɪləti| noun 负责 义务 职责

 

开放封闭原则（OCP）：Open-Closed Principle

 

接口隔离原则（ISP）：Interface Segregation Principle

    segregation |ˌsegrɪˈgeɪʃn| noun 分离 分开

 

substitute |ˈsʌbstɪtjuːt, American -tuːt| n 替身 vt 代替

segregate |ˈsegrɪgəɪt| v 使孤立、使....分开、隔开

signature |ˈsɪgnətʃə(r)| n 签名、签字