设计模式之六大设计原则【入门】

最新推荐文章于 2022-07-22 14:48:57 发布

wildyuhao

最新推荐文章于 2022-07-22 14:48:57 发布

阅读量130

点赞数

分类专栏： Java 文章标签：设计模式 java

本文链接：https://blog.csdn.net/wildyuhao/article/details/108892204

版权

Java 专栏收录该内容

29 篇文章 0 订阅

订阅专栏

1 开闭原则 Open Closed Principle，OCP

1.1 概念

软件实体应当对拓展开放，对修改关闭

1.2 软件实体

软件实体包括：1.项目中划分出的模块 2.类与接口 3.方法

1.3 开闭原则的作用

对软件测试的影响软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运行。
可以提高代码的可复用性粒度越小，被复用的可能性就越大；在面向对象的程序设计中，根据原子和抽象编程可以提高代码的可复用性。
可以提高软件的可维护性遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护。

2. 单一职责原则 Single responsibility principle，SRP

2.1 概念

一个类应该有且仅有一个引起他变化的原因，否则类应该被拆分

2.2 一个对象承担太多职责的缺点

一个职责的变化可能会削弱这个类实现其他职责的能力
当需要某个对象某个职责时，不得不将该对象其他职责包含进来

2.3 单一职责原则的优点

单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点：

降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
提高类的可读性。复杂性降低，自然其可读性会提高。
提高系统的可维护性。可读性提高，那自然更容易维护了。
变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。

3 里氏替换原则：Liskov Substitution Principle，LSP

3.1 概念

里氏替换原则存在父子类之间，包括两种原则：

第一种：If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.（如果每一个类型S的对象o1，都有一个类型T的对象o2，在以T定义的所有程序P中将所有的对象o2都替换为o1，而程序P的行为没有发生变化，那么S是T的子类。）。

第二种：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.（所有引用基类的地方必须能透明地使用其子类对象。）

3.2 四层含义

原则理解起来比较抽象，实际上里氏替换原则有以下四层含义：

子类必须完全实现父类的方法。
子类中可以增加自己特有的方法。
当子类覆盖或实现父类的方法时，方法的输入参数（方法的形参）要比父类方法的输入参数更宽松

public class LSP { 
class Parent { 
public void fun(HashMap map){ 
System.out.println("父类被执行..."); 
} 
}
class Sub extends Parent{ 
public void fun(Map map){ 
System.out.println("子类被执行..."); 
} 
}
public static void main(String[] args){ 
System.out.print("父类的运行结果："); 
LSP lsp =new LSP(); 
Parent a= lsp.new Parent(); 
HashMap<Object, Object> map=new HashMap<Object, Object>(); 
a.fun(map); 
//父类存在的地方，可以用子类替代 
//子类B替代父类ASystem.out.print("子类替代父类后的运行结果："); 
LSP.Sub b=lsp.new Sub(); 
b.fun(map); 
} 
}

ps:这里子类并非重写了父类的方法，而是重载了父类的方法。因为子类和父类的方法的输入参数是不同的。 
子类方法的参数Map比父类方法的参数HashMap的范围要大，所以当参数输入为HashMap类型时，只会执行父类的方法，不会执行父类的重载方法。这符合里氏替换原则。

当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格

3.3 里氏替换原则作用

里氏替换原则是实现开闭原则的重要方式之一。
它克服了继承中重写父类造成的可复用性变差的缺点。
它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。

4 依赖倒置原则：Dependence Inversion Principle，DIP

4.1 概念

依赖倒置原则的原始定义为:High level modules should not depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions。
其实里面包含了三层含义：

高层模块不应该依赖低层模块，两者都应该依赖其抽象；
抽象不应该依赖细节，
细节应该依赖抽象。

核心思想：要面向接口编程，不要面向实现编程。

4.2 依赖倒置原则的作用

依赖倒置原则可以降低类间的耦合性。
依赖倒置原则可以提高系统的稳定性。
依赖倒置原则可以减少并行开发引起的风险。
依赖倒置原则可以提高代码的可读性和可维护性。

5 接口隔离原则:Interface Segregation Principle，ISP

5.1 概念

接口隔离原则要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。
2002 年罗伯特·C.马丁给“接口隔离原则”的定义是：客户端不应该被迫依赖于它不使用的方法（Clients should not be forced to depend on methods they do not use）。该原则还有另外一个定义：一个类对另一个类的依赖应该建立在最小的接口上（The dependency of one class to another one should depend on the smallest possible interface）。
以上两个定义的含义是：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

5.2 接口隔离原则和单一职责原则的区别

接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：

单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。

5.3 接口隔离原则的优点

接口隔离原则是为了约束接口、降低类对接口的依赖性，遵循接口隔离原则有以下 5 个优点。

将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。
如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。
使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。

5.4 接口隔离原则的实现方法

在具体应用接口隔离原则时，应该根据以下几个规则来衡量。

接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。
提高内聚，减少对外交互。使接口用最少的方法

6 迪米特法则：Law of Demeter，LoD

6.1 概念

迪米特法则（Law of Demeter，LoD）又叫作最少知识原则（Least Knowledge Principle，LKP)，产生于 1987 年美国东北大学（Northeastern University）的一个名为迪米特（Demeter）的研究项目，由伊恩·荷兰（Ian Holland）提出，它要求一个对象应该对其他对象有最少的了解。通俗的说，一个类应该对自己需要耦合或调用的类知道的最少，被耦合或调用的类的内部是如何复杂都与我无关，我就知道你提供的public方法就好。

迪米特法则还是在讲如何减少耦合的问题，类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。也就是说，信息的隐藏促进了软件的复用。

迪米特法则还有一个定义是：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。什么叫做直接的朋友呢？每个对象都必然会和其他对象有耦合关系，两个对象之间的耦合就成为朋友关系，这种关系有很多比如组合、聚合、依赖等等。包括以下几类：