软件设计中的五大原则

软件设计中的五大原则

一、 SRP The Single Responsibility Principle 单一职责原则

陈述：就一个类而言，应该只有一个导致其变化的原因

分析：

一个职责就是一个变化的轴线

一个类如果承担的职责过多，就等于将这些职责耦合在一起。一个职责的变化可能会虚弱或者抑止这个类完成其它职责的能力

–多职责将导致脆弱性的臭味

什么是职责？职责就是变化的原因。

二、OCP， 开发封闭原则

陈述：

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

（1）对扩展是开放的

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

（2）对更改是封闭的

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

分析：

世界是变化的（而且变化很快），软件是对现实的抽象

软件必须能够扩展

如果任何修改都需要改变已经存在的代码，那么可能导致牵一发动全身现象，进而导致雪崩效应，使软件质量显著下降

实现OCP的关键是抽象。

OCP原则其实是要求我们清晰的区分策略和策略的具体实现形式。允许

扩展具体的实现形式（开放），同时将这种扩展与策略隔离开来，使

其对上层的策略透明（封闭）

三、The Liskov Substitution Principle 可替换原则。LSP

陈述：子类型（Subtype）必须能够替换他们的基类型(Basetype)

Barbara Liskov对原则的陈述：

若对每个类型S的对象o1,都存在一个类型T的对象o2，使得在所有针对T编写的程序P中，用o1替换o2后，程序P的行为功能不变，则S是T的子类型。

分析：

违法这个职责将导致程序的脆弱性和对OCP的违反

例如：基类Base，派生类Derived，派生类实例d,函数f(Base* p);

f(&d) 会导致错误 显然D对于f是脆弱的。

如果我们试图编写一些测试，以保证把d传给f时可以使f具有正确的行为。那么这个测试违反了OCP——因为f无法对Base的所有派生类都是封闭的
OOD中对象之间是否存在IS-A关系，应该从行为的角度来看待。

->而行为可以依赖客户程序做出合理的假设。

四、依赖倒置原则 DIP， The Dependency Inversion Principle

陈述：

高层模块不应该依赖于低层模块。二者应该依赖于抽象。

抽象不应该依赖于细节。细节应该依赖于抽象。

分析：

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

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

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

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

五、接口隔离原则 ISP

陈述：

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

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