设计模式_01(七大原则)

点击跳转设计模式目录

一、设计模式七大原则

1.单一职责原则

2. 接口隔离原则

3. 依赖倒转(倒置)原则

4. 里氏替换原则

5. 开闭原则(ocp)

6. 迪米特法则

7. 合成复用原则

　　使用设计模式的目的是提高代码重用性、可读性、可扩展性(可维护性)和可靠性(当增加新的功能后，对原来的功能没有影响)，使程序呈现高内聚、低耦合的特性。

1.1 单一职责原则

对类来说，即一个类应该只负责一项职责。

单一职责原则细节：

减低类的复杂度，一个类只负责一项职责
提高类的可读性和可维护性
降低变更引起的风险
通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则：只有类中方法数量足够少，可以在方法级别保持单一职责原则

案例：构建交通工具类

//方式1
public class SingleResponsibility1 {
	public static void main(String[] args) {
		Vehicle vehicle = new Vehicle();
		vehicle.run("自行车");
		vehicle.run("飞机");
	}
}
//交通工具类
class Vehicle {
	public void run(String vehicle) {
		System.out.println(vehicle +"在公路上跑....");
	}
}

观察上述方式1实现会发现Vehicle违反了单一职责原则，因为它的run方法本来只负责在公路上跑的职责，但是当时飞机的时候，依然是它来处理。解决方案是将类分解，分解为符合单一职责原则即可。

//方式2
public class SingleResponsibility2 {
	public static void main(String[] args) {
		RoadVehicle roadVehicle = new RoadVehicle();
		roadVehicle.run("自行车");
		AirVehicle airVehicle = new AirVehicle();
		airVehicle.run("飞机");
	}
}

//路上交通工具
class RoadVehicle {
	public void run(String vehicle) {
		System.out.println(vehicle +"在公路上运行...");
	}
}
//空中交通工具
class AirVehicle {
	public void run(String vehicle) {
		System.out.println(vehicle +"在天空中运行...");
	}
}
//水上交通工具
class WaterVehicle {
	public void run(String vehicle) {
		System.out.println(vehicle +"在水中运行...");
	}
}

观察方式2可以发现虽然遵守单一职责原则，但是做的改动是比较大的。如果方法数量足够少，可以在类的级别上违反单一职责原则，但是在方法级别上保持单一职责原则。如下方式3

//方式3
public class SingleResponsibility3 {
	public static void main(String[] args) {
		Vehicle3 vehicle = new Vehicle3();
		vehicle.run("自行车");
		vehicle.runAir("飞机");
	}
}

class Vehicle3 {
	public void run(String vehicle) {
		System.out.println(vehicle +"在公路上跑....");
	}
	public void runAir(String vehicle) {
		System.out.println(vehicle +"在天空上跑....");
	}
	public void runWater(String vehicle) {
		System.out.println(vehicle +"在水中跑....");
	}
}

1.2 接口隔离原则

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

案例：类A通过接口Interface1依赖类B，类C通过接口Interface1依赖类D。详情如下类图：

设计模式_01(七大原则)

//方式1
package com.principle.segregation;

public class Segregation01 {
	public static void main(String[] args) {
		A a = new A();
		//A依赖B
		a.fun1(new B());
		a.fun2(new B());
		a.fun3(new B());
		//C
		C c = new C();
		c.fun1(new D());
		c.fun2(new D());
		c.fun3(new D());
	}
}
interface Interface1 {
	void operation1();
	void operation2();
	void operation3();
	void operation4();
	void operation5();
}
//类B实现接口
class B implements Interface1 {
	@Override
	public void operation1() {
		System.out.println("类B实现接口");
	}
	@Override
	public void operation2() {
		System.out.println("类B实现接口");
	}
	@Override
	public void operation3() {
		System.out.println("类B实现接口");
	}
	@Override
	public void operation4() {
		System.out.println("类B实现接口");
	}
	@Override
	public void operation5() {
		System.out.println("类B实现接口");
	}
}
//类D实现接口
class D implements Interface1 {
	@Override
	public void operation1() {
		System.out.println("类D实现接口");
	}
	@Override
	public void operation2() {
		System.out.println("类D实现接口");
	}
	@Override
	public void operation3() {
		System.out.println("类D实现接口");
	}
	@Override
	public void operation4() {
		System.out.println("类D实现接口");
	}
	@Override
	public void operation5() {
		System.out.println("类D实现接口");
	}
}
//类A通过接口依赖类B，同时只会使用方法1.2.3
class A {
	void fun1(Interface1 i) {
		i.operation1();
	}
	void fun2(Interface1 i) {
		i.operation2();
	}
	void fun3(Interface1 i) {
		i.operation3();
	}
}
//类C通过接口依赖类D，同时只会使用1,4,5
class C{
	void fun1(Interface1 i) {
		i.operation1();
	}
	void fun2(Interface1 i) {
		i.operation4();
	}
	void fun3(Interface1 i) {
		i.operation5();
	}
}

分析上述方式1实现方法，会发现违反了接口隔离原则，此时B类的operator4()、orerator5()和D类的operator2()、operator3()都是多余的操作。所以只需要将A进行拆分，已达到接口隔离原则，如下：

//方式2
/将原接口A拆分为三个独立接口，分别包含operation1(),operation2()、operation3(),operation4()、operation5();
interface Interface01 {
	void operation1();
}
interface Interface02 {
	void operation2();
	void operation3();
}
interface Interface03 {
	void operation4();
	void operation5();
}
//类B实现接口
class B2 implements Interface01, Interface02 {
	@Override
	public void operation1() {
		System.out.println("类B实现接口");
	}
	@Override
	public void operation2() {
		System.out.println("类B实现接口");
	}
	@Override
	public void operation3() {
		System.out.println("类B实现接口");
	}
}
//类D实现接口
class D2 implements Interface01, Interface03 {
	@Override
	public void operation1() {
		System.out.println("类D实现接口");
	}
	@Override
	public void operation4() {
		System.out.println("类D实现接口");
	}
	@Override
	public void operation5() {
		System.out.println("类D实现接口");
	}
}

即当违反接口隔离原则时，可通过拆分接口，然后使实现类继承多借口来满足接口隔离原则。

1.3 依赖倒转原则

高层模块不应该依赖底层模块，二者都应该依赖其抽象
抽象不应该依赖细节，细节应该依赖抽象
依赖倒转(倒置)的中心思想是面向接口编程

      依赖倒转的原则是基于这样的理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的结构比以细节为基础的架构要稳定的多。在java中，抽象指的是接口或抽象类，细节就是具体的实现类。

      使用接口或抽象类中的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

      依赖关系传递的三种方式：接口传递、构造方法传递、setter方法传递。

注意事项：
底层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好。
变量的声明类型尽量是抽象类或接口，这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化。
继承时遵循里氏替换原则(里氏替原则在下文介绍)。

案例：简单构建用户接受消息的功能系统

package com.principle.inversion;

public class Inversion {
	public static void main(String[] args) {
		User user = new User();
		user.receive(new Email());
	}
}
class User {
	public void receive(Email email) {
		System.out.println(email.getInfo());
	}
}

class Email {
	public String getInfo() {
		return "Email返回数据";
	}
}

分析上述方式1写法，如果此时我们添加需求，用户除了可以使用Email接受信息外，还可以使用微信和短信接受信息，这时会发现如果我们继续按照这种设计思路来实际的话，只能如下设计：

//方式1，增加需求
public class Inversion {
	public static void main(String[] args) {
		User user = new User();
		user.receive(new Email());
		user.receive(new WeChat());
		user.receive(new Message());
	}
}
class User {
	public void receive(Email email) {
		System.out.println(email.getInfo());
	}
	//新增需求，增加微信、短信接受消息
	public void receive(WeChat weChat) {
		System.out.println(weChat.getInfo());
	}
	public void receive(Message message) {
		System.out.println(message.getInfo());
	}
	
}

class Email {
	public String getInfo() {
		return "Email返回数据";
	}
}
//新增需求，微信接受消息
class WeChat {
	public String getInfo() {
		return "微信返回数据";
	}
}
//短信接受消息
class Message {
	public String getInfo() {
		return "短信返回数据";
	}
}

观察上述设计思路，在增加需求时，不仅需要新增功能类，还需要修改原有的用户接受时的类User。这种修改时不方便且不稳定的，严重违反了依赖倒装原则。抽象Email、WeChat、Message类会发现都存在一个返回消息的方法，只是返回的方式可能不同，所以解决方案就是引入接口作为底层模块，让用户依赖接口使用不同的接受信息类。如下：

//方式2
public class Inversion {
	public static void main(String[] args) {
		User user = new User();
		user.receive(new Email());
		user.receive(new WeChat());
		user.receive(new Message());
	}
}
class User {
	//依赖接口，完成多态
	public void receive(IReceive i) {
		System.out.println(i.getInfo());
	}
	
}
//IReceive接口，定义接受信息规范
interface IReceive {
	String getInfo();
}
class Email implements IReceive{
	public String getInfo() {
		return "Email返回数据";
	}
}
//新增需求，微信接受消息
class WeChat implements IReceive{
	public String getInfo() {
		return "微信返回数据";
	}
}
//短信接受消息
class Message implements IReceive{
	public String getInfo() {
		return "短信返回数据";
	}
}

观察方式2的设计思路会发现，此时就算再增加需求，也只需要增加一个继承自IReceive的类即可，完全不需要修改User类。这既是依赖倒转原则的好处，增强程序稳定性，利于程序的扩展和优化

1.4 里氏替换原则

继承的思考：

继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。
继承在给程序设计带来便利的同时，也带来了弊端。如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障。

里氏替换原则：

1. 如果对每个类型为T1的对象o1，都有类型T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。

2. 在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法。

3. 里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合、组合、依赖来解决问题。

4. 通常做法：原来的父类和子类都继承一个通俗的基类，原来的继承关系去掉，采用依赖、聚合、租户等关系代替。

1.5 开闭原则

一个软件实体如类、模块和函数应该对扩展(提供方)开放，对修改(使用方)关闭。用抽象构建框架，用实现扩展细节。
当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

1.6 迪米特法则

一个对象应该对其他对象保持最少的了解
类与类关系越密切，耦合度越大
迪米特法则又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于依赖的类不管多么复杂，都尽量将逻辑封装在类的内部，对外除了提供的public方法，不泄露任何信息。
简单定义：只与直接的朋友通信
直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多：依赖、关联、组合、聚合等。其中，我们称出现在成员变量、方法参数、方法返回值的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最后不要以局部变量的形式出现在类的内部。

1.7 合成复用原则

原则是尽量使用合成/聚合的方式，而不是使用继承。

设计原则核心思想

找出应用可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
针对接口编程，而不是针对实现编程。
为了交互对象之间的松耦合设计而努力。

二、UML类图

依赖(使用)、关联、泛化(继承)、实现、聚合(成员变量，生命周期小于关联的类(使用set实例))、组合(成员变量，生命周期与关联的类相同)。

依赖关系：只要是在类中使用到了对方，那么他们之间就存在依赖关系。如类的成员属性、方法的返回值类型、接手的参数类型、方法的局部变量。
泛化关系：实际上就是继承关系，它是依赖关系的特例。
实现关系：A类实现了B类(接口)，它是依赖关系的特例
关联关系：实际上是类与类之间的联系，它是依赖关系的特例。关联关系具有导航型：即双向关系或单向关系。同时关联关系也具有多重性，即一对一(单向、双向)、一对多、多对一、多对
聚合关系：整体和部分的关系(可分离)，整体与部分可以分开。聚合关系是关联关系的特例，也具有导航型和多重性。
组合关系：如果整体和部分不可分离，则就升级为了组合关系。如果两个类之间进行级联删除，那么这两个类之间也可以看作是组合关系。

三、设计模式分类

创建型模式：单例模式、抽象工厂模式、原型模式、建造者模式、工厂模式
结构性模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式
行为型模式：模板方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式(Interpreter模式)、状态模式、策略模式、职责链模式(责任链模式)

设计模式_01(七大原则)

一、设计模式七大原则

1.1 单一职责原则

1.2 接口隔离原则

1.3 依赖倒转原则

1.4 里氏替换原则

1.5 开闭原则

1.6 迪米特法则

1.7 合成复用原则

二、UML类图

三、设计模式分类

继续阅读

关于Gradle配置的小结

Java小案例——随机数猜测随机数猜测

nginx location中斜线的位置的重要性

27 Best Free Eclipse Plug-ins for Java Developer to be ProductiveCode Quality PluginsText Editor PluginsDependency ManagementVersion Control Integration PluginsFramework Development Continuous Integration Related PluginsOther Utility Plugins

Java String.format方法的简单使用

neo4j之cypher使用文档

GitHub连夜封杀！这份阿里 10W 字内部 Java 字面试手册到底有多强？

spark/scala关于【资源文件】加载方法概述外部文件加载方案测试资源文件打包入jar包中小结

mybatis_入门程序Mybatis入门

AOP编程_Android优雅权限框架(1)概念基础，2021金三银四前言正文大纲正文

Effective Java 8:通用程序设计

OOM三种类型

工厂模式-三种类型

【递归】高效率求2的n次幂

win10本地scala和spark安装安装scala安装spark

scala (3) Function 和 Method