面向对象设计原则

1．概述汇总

对于面向对象软件系统的设计而言，在支持可维护性的同时，提高系统的可复用性是一个至关重要的问题，如何同时提高一个软件系统的可维护性和可复用性是面向对象设计需要解决的核心问题之一。在面向对象设计中，可维护性的复用是以设计原则为基础的。每一个原则都蕴含一些面向对象设计的思想，可以从不同的角度提升一个软件结构的设计水平。
面向对象设计原则为支持可维护性复用而诞生，这些原则蕴含在很多设计模式中，它们是从许多设计方案中总结出的指导性原则。面向对象设计原则也是我们用于评价一个设计模式的使用效果的重要指标之一，在设计模式的学习中，大家经常会看到诸如“XXX模式符合XXX原则”、“XXX模式违反了XXX原则”这样的语句。

面向对象的设计原则最重要最核心的原则就是开闭原则,很多其它的原则都是为了实现开闭原则来实现的.


最常见的7种面向对象设计原则如下表所示：

2．单一职责原则SRP

类应该只有一个导致类变更的理由,即一个类只负责一项职责,也就是一个类或者一个接口只负责唯一项职责，尽量设计出功能单一的接口；

目的:
1. 降低类的复杂度
2. 提高系统的可维护性
3. 修改时降低风险溢出

优点:
1. 降低类的复杂性(一个类只负责一项职责,对于它的逻辑肯定要比负责多项职责简单的多)
2. 提高类的可读性(因为类简单了,所以就更容易读了.)
3. 提高系统的可维护性(因为类简单了)
4. 降低变更引起的风险.(代码变更是必然的,根据需求修改代码也是没办法的,我们如果遵守单一职责原则的好,那么就显著降低修改A功能对B功能的影响)

解读:
单一职责原则告诉我们：一个类不能太“累”！在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小
而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作(假如说我修改A功能,B功能可能会受到影响,导致B功能会失效出现bug)
因此要将这些职责进行分离，将不同的职责封装在不同的类中(A功能封装到A类,B功能封装到B类中)，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。

这样好处就是修改了A功能,减少了B功能出现牵连的概率

单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验。单一职责原则不只是面向对象编程,只要是模块儿化的设计都可以使用单一职责原则.

当然我们要根据实际情况(考虑开发成本,时间,进度)来决定是否完全遵守单一原则.

体现在哪些方面呢:
1. 接口级别的单一原则
2. 方法级别不说了,就是一个方法只有一个职责.
3. 类级别不说了就是一个类只有一个职责

3．开闭原则OCP

程序对外扩展开放，对修改关闭；换句话说，当需求发生变化时，我们可以通过添加新模块来满足新需求，而不是通过修改原来的实现代码来满足新需求；

设计的目的便在于面对需求的改变而保持系统的相对稳定，从而使得系统可以很容易的从一个版本升级到另一个版本。



实际上，绝对封闭的系统是不存在的。无论模块是怎么封闭，到最后，总还是有一些无法封闭的变化。而我们的思路就是：既然不能做到完全封闭，那我们就应该对那些变化封闭，那些变化隔离做出选择。我们做出选择，然后将那些无法封闭的变化抽象出来，进行隔离，允许扩展，尽可能的减少系统的开发。当系统变化来临时，我们要及时的做出反应。
我们并不害怕改变的到来。当变化到来时，我们首先需要做的不是修改代码，而是尽可能的将变化抽象出来进行隔离，然后进行扩展。面对需求的变化，对程序的修改应该是尽可能通过添加代码来实现，而不是通过修改代码来实现。
实际上，变化或者可能的变化来的越早，抽象就越容易，相对的，代码的维护也就越容易；而当项目接近于完成而来的需求变化，则会使抽象变得很困难——这个困难，并不是抽象本身的困难，抽象本身并没有困难，困难在于系统的架构已经完成，修改牵扯的方面太多而使得抽象工作变得很困难。
优点:
1. 提高可维护性,需要新的扩展,你只需要重写实现一个类即可,原来的类是不需要修改,也就是不需要重新测试.(主要是已经上线的代码,你不能贸然修改,万一修改了可能会出现未知的bug.)

2. 有些源码你没法修改,比如HashMap,如果你需要扩展HashMap,你没法修改源码,你可以通过extens HashMap然后重写你需要扩展的方法

怎么使用开闭原则

1. 抽象约束
抽象是对一组事物的通用描述， 没有具体的实现， 也就表示它可以有非常多的可能性，可以跟随需求的变化而变化。 因此， 通过接口或抽象类可以约束一组可能变化的行为， 并且能够实现对扩展开放， 其包含三层含义：
第一， 通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；
第二， 参数类型、 引用对象尽量使用接口或者抽象类， 而不是实现类；
第三， 抽象层尽量保持稳定， 一旦确定即不允许修改。

2. 元数据（metadata） 控制模块行为
编程是一个很苦很累的活， 那怎么才能减轻我们的压力呢？ 答案是尽量使用元数据来控制程序的行为， 减少重复开发。
什么是元数据？
用来描述环境和数据的数据， 通俗地说就是配置参数， 参数可以从文件中获得， 也可以从数据库中获得。典型的元数据控制模块行为的例子， 其中达到极致的就是控制反转（Inversion of Control） ，使用最多的就是Spring容器， 扩展一个子类， 修改SpringContext配置文件， 完成了业务变化， 这也是采用框架的好处。
3. 封装变化
对变化的封装包含两层含义： 第一， 将相同的变化封装到一个接口或抽象类中； 第二，将不同的变化封装到不同的接口或抽象类中， 不应该有两个不同的变化出现在同一个接口或抽象类中。 封装变化， 也就是受保护的变化（protected variations） ， 找出预计有变化或不稳定的点， 我们为这些变化点创建稳定的接口， 准确地讲是封装可能发生的变化， 一旦预测到或“第六感”发觉有变化， 就可以进行封装， 23个设计模式都是从各个不同的角度对变化进行封装的， 我们会在各个模式中逐步讲解。



如果需要修改某个类的代码,只需要extends原来的类,对需要扩展的方法进行重写即可.


参考:
https://blog.csdn.net/chy2z/article/details/81240486

4．里氏代换原则LSP

里氏替换原则是1988年麻省理工姓李的女士提出，它是阐述了对继承extends的一些看法。
继承的优点：
1. 提高代码的重用性，子类也有父类的属性和方法。
2. 提高代码的可扩展性，子类有自己特有的方法。
继承的缺点：
1. 当父类发生改变的时候，要考虑子类的修改。
2. 里氏替换原则是继承的基础，只有当子类替换父类时，软件功能仍然不受到影响，才说明父类真正被复用啦。




子类可以去扩展父类，但是不能改变父类原有的功能。

所有引用基类（父类）的地方必须能透明地使用其子类的对象；里氏代换原则是对开闭原则的一个补充,讲的是基类和子类的关系.

当程序基于父类实现时,如果将子类替换父类而程序不需要修改,则说明符合LSP原则,也就是说子类必须能替换成它们的父类.

通俗点讲， 只要父类能出现的地方子类就可以出现， 而且替换为子类也不会产生任何错误或异常， 使用者可能根本就不需要知道是父类还是子类。 但是，反过来就不行了， 有子类出现的地方， 父类未必就能适应。


具体原则:
1. 子类必须完全实现父类的方法,否则调用者调用了一个父类中有,而子类中没有的方法.运行时就会出错;
2. 子类可以有自己的方法和属性,

子类每个方法的输入参数必须和父类一样,否则调用父类的代码不能调用子类;
子类每个方法的输出(返回值,修改全局变量,插入数据库,发送网络数据等)必须不比父类少(可以比父类多),否则基于父类的输出做的处理就没法完成.

举个例子，“长方形”是基类，“正方形”是一种特殊的长方形，理所应当“正方形”是“长方形”的子类。“长方形”有单独改变长或宽的行为，对于“正方形”来说，就得改写这两个行为以保证长等于宽。这样就违背了里氏替换原则。当长方形调整了长，又调整宽，在算面积的时候。正方形这个子类就会出错。

比如“鸟”是基类，这个基类有一个“飞翔”的行为。当“鸵鸟”继承了“鸟”，这就会引起麻烦，覆写基类“飞翔”的行为吧，这样就不再符合里氏替换原则。“鸵鸟”是不能替换它的基类了。

使用里氏代换原则需要注意以下几点:

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

5．依赖倒置原则DIP

Dependence Inversion Principle

定义

抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。

高层模块不应该依赖低层模块具体实现，解耦高层与低层。既面向接口编程，当实现发生变化时，只需提供新的实现类，不需要修改高层模块(就是调用接口的类)代码;

详细介绍:
依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增加的新方法。

在实现依赖倒转原则时，我们需要针对抽象层编程，而将具体类的对象通过依赖注入(DependencyInjection, DI)的方式注入到其他对象中，依赖注入是指当一个对象要与其他对象发生依赖关系时，通过抽象来注入所依赖的对象。常用的注入方式有三种，分别是：构造注入，设值注入（Setter注入）和接口注入。构造注入是指通过构造函数来传入具体类的对象，设值注入是指通过Setter方法来传入具体类的对象，而接口注入是指通过在接口中声明的业务方法来传入具体类的对象。这些方法在定义时使用的是抽象类型，在运行时再传入具体类型的对象，由子类对象来覆盖父类对象。

为什么要面向接口编程?
比如说Spring框架, 你方法成员变量那里.@Autowired 就是注入的接口.
因为用户服务器的实现是可能会发生变化的,比如是基于数据库查询的,或者是从缓存里面查询的,可能业务会不停的变化,如果说是在Controller层直接依赖它的实现类的话,每当它的实现发生变化的话,调用的Controller层那里代码都要跟着变.

JDBC也是典型的面向接口编程的代码,因为JDBC的Connection有MySQL的实现也有Oracle的实现或者别的代码,如果你换了数据库的话,业务代码是不需要修改的.这也就是面向接口编程的好处.

优点:
可以减少类间的耦合性,提高系统稳定性,提高代码可读性和可维护性,可降低修改程序所造成的风险.

可以通过抽象使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合（也是本质）
可以规避一些非技术因素引起的问题（项目大时，需求变化的概率也越大，通过采用依赖倒置原则设计的接口或抽象类对实现类进行约束，可以减少需求变化引起的工作量剧增情况。同时，发生人员变动，只要文档完善，也可让维护人员轻松地扩展和维护）
可以促进并行开发（如，两个类之间有依赖关系，只要制定出两者之间的接口（或抽象类）就可以独立开发了，规范已经定好了，而且项目之间的单元测试也可以独立地运行，而TDD开发模式更是DIP的最高级应用（特别适合项目人员整体水平较低时使用））

6．接口隔离原则ISP

客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上；

使用多个专门的接口，不要建立臃肿庞大的单一的总接口，即客户端不应该依赖那些它不需要的接口.再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。

在使用接口隔离原则时，我们需要注意控制接口的粒度，接口不能太小，如果太小会导致系统中接口泛滥，不利于维护；接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。一般而言，接口中仅包含为某一类用户定制的方法即可，不应该强迫客户依赖于那些它们不用的方法。


根据接口隔离原则，当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。每一个接口应该承担一种相对独立的角色，不干不该干的事，该干的事都要干。这里的“接口”往往有两种不同的含义：一种是指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象；另外一种是指某种语言具体的“接口”定义，有严格的定义和结构，比如Java语言中的interface。对于这两种不同的含义，ISP的表达方式以及含义都有所不同：

1. 当把“接口”理解成一个类型所提供的所有方法特征的集合的时候，这就是一种逻辑上的概念，接口的划分将直接带来类型的划分。可以把接口理解成角色，一个接口只能代表一个角色，每个角色都有它特定的一个接口，此时，这个原则可以叫做“角色隔离原则”。

2. 如果把“接口”理解成狭义的特定语言的接口，那么ISP表达的意思是指接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。在面向对象编程语言中，实现一个接口就需要实现该接口中定义的所有方法，因此大的总接口使用起来不一定很方便，为了使接口的职责单一，需要将大接口中的方法根据其职责不同分别放在不同的小接口中，以确保每个接口使用起来都较为方便，并都承担某一单一角色。接口应该尽量细化，同时接口中的方法应该尽量少，每个接口中只包含一个客户端（如子模块或业务逻辑类）所需的方法即可，这种机制也称为“定制服务”，即为不同的客户端提供宽窄不同的接口。

接口隔离原则和单一职责原则区别
接口隔离原则与单一职责的审视角度是不相同的，单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，
而接口隔离原则要求接口的方法尽量少。例如一个接口的职责可能包含10个方法，这10个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，在系统外通过文档约束“不使用的方法不要访问”，按照单一职责原则是允许的，按照接口隔离原则是不允许的，
因为它要求“尽量使用多个专门的接口”。专门的接口指什么？就是指提供给每个模块的都应该是单一接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿的接口，容纳所有的客户端访问。

7．合成复用原则

尽量使用对象组合，而不是继承来达到复用的目的。

为什么尽量不要使用继承?
这是因为：

第一，继承复用破坏包装，它把父类的实现细节直接暴露给了子类，这违背了信息隐藏的原则；
第二：如果父类发生了改变，那么子类也要发生相应的改变，这就直接导致了类与类之间的高耦合，不利于类的扩展、复用、维护等，也带来了系统僵硬和脆弱的设计。而用合成和聚合的时候新对象和已有对象的交互往往是通过接口或者抽象类进行的，就可以很好的避免上面的不足，而且这也可以让每一个新的类专注于实现自己的任务，符合单一职责原则。

8．迪米特法则

迪米特法则(Law of Demeter, LoD)：一个软件实体应当尽可能少地与其他实体发生相互作用。


也是最少知道原则

一个对象应该对其他对象保持最少的了解，尽量降低类与类之间的耦合度；

在将迪米特法则运用到系统设计中时，要注意下面的几点：在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波及；在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限；在类的设计上，只要有可能，一个类型应当设计成不变类；在对其他类的引用上，一个对象对其他对象的引用应当降到最低。

迪米特法则实现原则
1. 在类结构设计的时候,尽量降低类成员变量的访问权限,能用private就不要用public
2. 类之间尽量不要有依赖关系(这个法则强调的是类之间的松耦合.)