程序设计六大原则

目录

单一职责原则（Single Responsibility Principle）

开闭原则（Open Closed Principle）

里氏替换原则（Liskov Substitution Principle）

依赖倒置原则（Dependence Inversion Principle）

         接口隔离原则（Interface Segregation Principle）

迪米特原则（Law of Demeter）一个软件实体应当尽可能少地与其他实体发生相互作用

---

单一职责原则（Single Responsibility Principle）

简单来说单一职责就是一个类只负责一个功能。更加具体的说就是对一个类而言，应该是一组相关性很高的函数、数据的封装，是高内聚低耦合的，对外界而言应该仅有一个引起它变化的原因。

• 单一职责在项目中的使用:

1. 项目中的新手引导变量的管理可以统一在各自的Modle中用单独的类来管理
2. MVP模式P层生命周期与V层生命周期的同步可以用单独的包装类来实现，
3. 各种基础框架功能的定义，例如：图片的加载、缓存、显示等都应该在各自的类中去做。

开闭原则（Open Closed Principle）

一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。

在软件的生命周期内，因为变化、升级和维护等原因需要对软件的原有代码进行修改时，可能会将错误的代码引入，从而破坏原有系统。因此当软件需求发生变化时，我们应该尽量通过扩展的方式 来实现变化，而不是通过修改已有的代码。

• 开闭原则在项目中的使用:

1. 基类与子类，子类可以继承父类并扩展父类的功能
2. 接口与实现类，接口定义功能，实现类按照各自的需求实现

里氏替换原则（Liskov Substitution Principle）

• 定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。
• 定义2：所有引用基类的地方必须能透明地使用其子类的对象。
• 通俗点讲，父类能够替换子类，但子类不一定能替换父类。也就是说，在代码中可以将父类全部替换为子类，程序不会报错，也不会在运行时出现任何异常，但反过来却不一定成立。

里氏替换原则的核心是抽象，而抽象又依赖于继承这个特性，在OOP当中，继承的优缺点都相当明显。

• 优点：

1. 代码重用，减少创建类的成本，每个子类都拥有父类的方法和属性
2. 子类与父类基本相似，但又与父类有所区别
3. 提高代码的可扩展性

• 缺点:

1. 继承是侵入性的，只要继承就必须拥有父类的方法和属性
2. 可能造成子类代码冗余，灵活性降低，因为子类必须拥有父类的属性和方法

里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

在使用里氏代换原则时需要注意如下几个问题：

1. 子类的所有方法必须在父类中声明，或子类必须实现父类中声明的所有方法。根据里氏代换原则，为了保证系统的扩展性，在程序中通常使用父类来进行定义，如果一个方法只存在子类中，在父类中不提供相应的声明，则无法在以父类定义的对象中使用该方法。
2. 我们在运用里氏代换原则时，尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法，运行时，子类实例替换父类实例，我们可以很方便地扩展系统的功能，同时无须修改原有子类的代码，增加新的功能可以通过增加一个新的子类来实现。里氏代换原则是开闭原则的具体实现手段之一。

应用：在继承类时，务必重写（Override）父类中所有的方法，尤其需要注意父类的 protected 方法，子类尽量不要暴露自己的 public 方法供外界调用。

依赖倒置原则（Dependence Inversion Principle）

• 抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。
• 依赖倒置原则指定了一种特定的解耦形式，使得高层次的模块不依赖与低层次模块的实现细节的目的，依赖模块被颠倒了。依赖倒置原则有以下几个关键点:

1. 高层模块不应该依赖于低层模块，两者都应该依赖其抽象
2. 抽象不应该依赖于细节
3. 细节应该依赖于抽象

 

开闭原则是目标，里氏代换原则是基础，依赖倒转原则是手段，它们相辅相成，相互补充，目标一致，只是分析问题时所站角度不同而已。

接口隔离原则（Interface Segregation Principle）

• 使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
• 类之间的依赖关系应该建立在最小的接口上

迪米特原则（Law of Demeter）一个软件实体应当尽可能少地与其他实体发生相互作用

一个软件实体应当尽可能少地与其他实体发生相互作用

通俗的讲，一个类应该对自己需要耦合或调用的类知道的最少，类的内部如何实现与调用者或者依赖者没有关系，调用者或者依赖者只需要知道他需要的方法即可，其他的一概不管。类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。