设计模式之六大原则理解

ゝ一世哀愁。 2022-11-03 14:30 154阅读 0赞

### 1.开放-关闭原则 ###

对扩展开放，对修改关闭，简称开闭原则。对软件实体(类，函数，模块等)应该是可以扩展，但是不可修改

这个原则是核心，其他的的设计模式和原则最终都为了达成这个目标，即让新增的需求能快速简单的做完，同时不影响线上其他功能的正常运行

### 2.单一职责原则 ###

一个类应该仅有一个引起它变化的原因，或者说只负责做一件事情

### 3.依赖倒置原则（Dependence Inversion Principle） ###

抽象不应该依赖细节，细节应该依赖于抽象。简单说就是，我们要针对接口编程，而不要针对实现编程。

高层模块不应该依赖低层模块，两个都应该依赖抽象，因为抽象是稳定的。抽象不应该依赖具体（细节），具体（细节）应该依赖抽象。

**距离：**类A直接依赖类B，假如要将类A改为依赖类C，则必须修改类A的代码,而且改动范围较大很麻烦。这种场景下，类A一般是高层模块，负责业务逻辑；类B和类C是低层模块

**解决：**将类A修改为依赖接口Interface，类B和类C各自实现接口Interface，类A通过接口Interface间接与类B或者类C发生联系，则会大大降低修改类A的几率。

依赖倒置原则的使用建议：

（1）每个类尽量都有接口或抽象类，或者接口和抽象类两者都具备。

（2）变量的表面类型尽量是接口或抽象类。类似这种：IChart chart=new Chart();

（3）任何类都不应该从具体类派生。也就是说所有父类都应该是抽象类  PS：这只是建议，并不是必须的

（4）尽量不要重写基类的方法。如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要重写。 跟里氏替换类似

### 4.接口隔离原则（Interface Segregation Principle, ISP） ###

使用多个专门的接口比使用单一的总接口好。不要让一个单一的接口承担过多的职责，而应把每个职责分离到多个专门的接口中，进行接口分离。过于臃肿的接口是对接口的一种污染

解决：把大的，具有十几个方法属性的接口，拆成多个小的接口

### 5.里氏替换原则  ###

***在面向对象的语言中，继承是必不可少的、非常优秀的语言机制，它有如下优点：***

1.  代码共享，减少创建类的工作量，每个子类都拥有父类的属性和方法；
2.  提高代码的重用性；
3.  子类可以形似父类，但又异于父类；
4.  提高代码的可扩展性；
5.  提高产品或项目的开放性。

***有优点就必然存在缺点：***

1.  继承是侵入性的。只要继承，就必须拥有父类的属性和方法。
2.  降低代码的灵活性。子类会多一些父类的约束。
3.  增强了耦合性。当父类的常量、变量、方法被修改时，需要考虑子类的修改。

为了让“利”的因素发挥最大的作用，同时减少“弊”带来的麻烦，引入了里氏替换原则（LSP）。

由来：1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的

最正宗的定义是：如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代替o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。

通俗点讲：任何基类可以出现的地方，子类一定可以出现

当使用继承时，遵循里氏替换原则。子类A继承父类B时，除添加新的方法外，尽量不要重写*(override)*父类A的方法，也尽量不要重载*(函数同名加参数)*父类B的方法

不要去重写父类的方法，如果你发现你需要重写父类的非抽象方法，那么父类的方法还有什么意义？

还有就是重写的话，不要破坏原有的功能，就是这个方法重写了之后，还是实现一样逻辑的功能

***违反里氏替换原则的危害：***

*  反直觉。期望所有子类行为是一致的，但如果不一致可能需要文档记录，或者在代码跑失败后涨此知识；
 *  不可读。如果子类行为不一致，可能需要不同的逻辑分支来适配不同的行为，徒增代码复杂度；
 *  不可用。可能出错的地方终将会出错。

***如何避免违反里氏替换原则***

谈到如何避免，当然要基于里氏替换原则的定义，`与期望行为一致的替换`。

*  从行为出发来设计。在做抽象或设计时，不只是要从模型概念出发，还要从行为出发，比如一个经典的例子，正方形和长方形，从现实的概念中正方形是一个长方形，但是在计算其面积的行为上是不一致的。
 *  基于契约设计。这个契约即是基类方法签名、功能描述、参数类型、返回值等。在派生类的实现时，时刻保持派生类与基类的契约不被破坏。

### 6.迪米特原则 Law of Demeter 最少知识原则(Least Knowledge Principle) ###

**定义：**一个对象应该对其它对象有最少的了解，从而降低各个对象之间的耦合，让程序有更好的可扩展性。

### **7.组合复用原则 **Composite Reuse Principle, CRP ###

组合复用原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分。新对象通过向这些对象的委派达到复用已用功能的目的。简单地说，就是要尽量使用合成/聚合，尽量不要使用继承。

要使用好组合复用原则，首先需要区分”Has—A”和“Is—A”的关系。 “Is—A”是指一个类是另一个类的“一种”，是属于的关系，而“Has—A”则不同，它表示某一个角色具有某一项责任。导致错误的使用继承而不是聚合的常见的原因是错误地把“Has—A”当成“Is—A”.例如：鸡是动物，这就是“Is-A”的表现，某人有一个手枪，People类型里面包含一个Gun类型，这就是“Has-A”的表现。

小结：组合/聚合复用原则可以使系统更加灵活，类与类之间的耦合度降低，一个类的变化对其他类造成的影响相对较少，因此一般首选使用组合/聚合来实现复用；其次才考虑继承，在使用继承时，需要严格遵循里氏替换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。