2020-10-25

对Java设计模式七大原则的理解

七大原则：

1、开闭原则
2、单一职责原则
3、聚合/组合复用原则
4、迪米特法则
5、依赖倒置原则
6、里氏替换原则
7、接口隔离原则

开闭原则： 软件实体应该面向修改关闭，面向扩展开放。
实现的核心就是“抽象及封装”。把我们的相同的代码抽取出来，便于重用，这就是“闭”。把不同的代码也抽取出来，便于功能的拓展，这就是“开”。开闭原则是设计原则的核心原则，其他设计原则都是开闭原则的体现和补充。

单一职责原则： 一个类只应该有一个引诱它变化的原因，不要让一个类拥有多种变化的理由。换句话说，一个类只应该完成和一个职责相关的业务，不要让一个类承担过多的职责。如果存在多个改变这一个类的理由，就需要重新设计该类。
在以前的一篇博客中有谈到自己对单一职责很浅显的认知
https://editor.csdn.net/md/?articleId=108433867
对于这里对单一职责分离，尽量做到单一职责就行，不应强求。提出一个粒度的名词。粒度的大小根据业务来，一般来说，简单的职责，可以让一个类兼任。复杂职责，必须独立
（在软件工程中的概率：高内聚指的就是单一职责原则，一个类职责越单一，内聚度就越高）

聚合/组合复用原则： 尽量使用聚合/组合完成代码复用，少用继承复用。继承在Java中只能单根继承，不能通过继承实现多个类的代码复用。但是，聚合/组合可以。它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

迪米特法则： 软件实体之间，应该尽量减少交互，不要因为一个业务类的变化而导致另一个类的变化，不和陌生人说话。
一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的public方法，我就调用这么多，其他的一概不关心。

依赖倒置原则： 面向抽象编程，不要面向具体编程。尽量使用抽象耦合代替具体耦合。
依赖倒置原则中最重要的就是 “抽象” 二字，高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。
(低耦合指的就是依赖倒置原则)

里氏替换原则： 子类可以扩展父类的功能，但不能改变父类原有的功能。
父类出现的地方，子类一定可以替换，如果父类中的方法不适用，或者在子类中发生了畸变，则应该断开父子关系。父类的方法子类无条件继承，很可能导致父类方法在子类中不适用的情况。
在很多情况下，在设计初期我们类之间的关系不是很明确，里氏替换原则给了我们一个判断和设计类之间关系的基准：需不需要继承，以及怎样设计继承关系。

接口隔离原则： 使用专门的接口，比用统一接口好，便于项目的组织和分工。不要让开发者面对自己用不到的方法。
如果在项目开发中，所有开发者使用一个统一接口，当接口发生改变时，他们也不得不跟着改变。换而言之，一个开发者依赖了未使用但被其他开发者使用的接口，当其他开发者修改该接口时，依赖该接口的所有开发者都将受到影响。这显然违反了开闭原则，也不是我们所期望的。

小结：
这7种设计原则是软件设计模式必须尽量遵循的原则。
开闭原则是总纲，它告诉我们要对扩展开放，对修改关闭。
单一职责原则告诉我们实现类要职责单一。
聚合/组合复用原则告诉我们要优先使用组合或者聚合关系复用，少用继承关系复用。
迪米特法则告诉我们要降低耦合度。
依赖倒置原则告诉我们要面向接口编程。
里氏替换原则告诉我们不要破坏继承体系。
接口隔离原则告诉我们在设计接口的时候要精简单一。