设计模式简述

什么是设计模式？
软件工程中，设计模式（design pattern）是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。

设计模式的目的：

• 代码高可用（相同作用的代码能重复使用）
• 可读性（编程规范性）
• 可扩展性（增加新的功能时，非常方便）
• 可靠性（增加新的功能后，对原有的功能没有影响）
• 代码的高内聚、低耦合

设计模式分为三种类型，共23种：

1. 创建型模式：单例模式、抽象工厂模式、原型模式、建造者模式、工厂模式。
2. 结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。
3. 行为型模式：模版方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式（Interpreter模式）、状态模式、策略模式、职责链模式(责任链模式)。 注意：不同的书籍上对分类和名称略有差别

设计模式的原则

设计模式常用的七大原则（设计模式为什么这样设计的依据）：

1. 单一职责原则
2. 接口隔离原则
3. 依赖倒转（倒置）原则
4. 里氏替换原则
5. 开闭原则
6. 迪米特法则
7. 合成复用原则

单一职责原则（SRP）

单一职责原则（Single responsibility principle）：对类来说的，即一个类应该只负责一项职责。如类A负责两个不同职责：职责1，职责2。当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A按照相应的职责分解为 A1，A2这两个类，分别去负责职责1和职责2。
例如：Dao层中的接口，每一个接口只负责对应实体类的增删改查。

例：

/*** @author 小关同学* @create 2021/9/1*/
//交通工具类
//在run方法中，违反了单一职责原则
//解决方式：根据交通工具运行方式的不同，分成不同的职责类
class Vehicle{public void run(String vehicle){System.out.println(vehicle+"在公路上运行");}
}
public class SingleResponsibility1 {public static void main(String[] args) {Vehicle vehicle = new Vehicle();vehicle.run("汽车");vehicle.run("摩托车");vehicle.run("飞机");}
}

运行结果：

总运行结果我们可以看到，该交通工具类承担了不止一个职责，所以我们需要将它承担的职责再细分，分成相应承担不同职责的类或者方法

方案一：

/*** @author 小关同学* @create 2021/9/1*///在类这个级别上遵守单一职责原则
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+"在水中运行");}
}
public class SingleResponsibility2 {public static void main(String[] args) {RoadVehicle roadVehicle = new RoadVehicle();AirVehicle airVehicle = new AirVehicle();WaterVehicle waterVehicle = new WaterVehicle();airVehicle.run("飞机");roadVehicle.run("汽车");waterVehicle.run("船");}
}

运行结果：

方案二：

/*** @author 小关同学* @create 2021/9/1*/
//在方法级别上遵守单一职责原则（建议还是在类级别上遵守单一职责原则）
class Vehicle2{public void runRoad(String vehicle){System.out.println(vehicle+"在公路上运行");}public void runAir(String vehicle){System.out.println(vehicle+"在天空中运行");}public void runWater(String vehicle){System.out.println(vehicle+"在水中运行");}
}
public class SingleResponsibility3 {public static void main(String[] args) {Vehicle2 vehicle2 = new Vehicle2();vehicle2.runAir("飞机");vehicle2.runRoad("汽车");vehicle2.runWater("轮船");}
}

运行结果：

有人可能会问，我使用if-else的方法也能实现上面两种方法的效果，为什么还要这个原则呢？
解释：使用if-else虽然也能完成上面的效果，但是会造成代码的耦合度和复杂度变高，耦合度高了我们以后再进行修改可能就会出现一些问题。

单一职责原则注意事项和细节：

• 降低类的复杂度，一个类只负责一项职责。
• 提高类的可读性，可维护性
• 降低变更引起的风险

通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级别违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则

接口隔离原则（ISP）

接口隔离原则（Interface Segregation Principle）的定义：

• 客户端不应该依赖它不需要的接口
• 类间的依赖关系应该建立在最小的接口上

其实通俗来理解就是，不要在一个接口里面放很多的方法，这样会显得这个类很臃肿不堪。接口应该尽量细化，一个接口对应一个功能模块，同时接口里面的方法应该尽可能的少，使接口更加轻便灵活。

接口隔离原则和单一职责原则的区别：
接口隔离原则和单一职责原则的审视角度是不同的，单一职责原则要求类和接口职责单一，注重的是职责，是业务逻辑上的划分，而接口隔离原则要求方法要尽可能的少，是在接口设计上的考虑。总之，接口隔离原则要“瘦接口”，不要“胖接口”。

依赖倒转原则（DIP）

依赖倒转原则(Dependence Inversion Principle)是指：

1. 高层模块不应该依赖低层模块，二者都应该依赖其抽象
2. 抽象不应该依赖细节，细节应该依赖抽象
3. 依赖倒转(倒置)的中心思想是面向接口编程
4. 依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在Java中，抽象指的是接口或抽象类，细节就是具体的实现类
5. 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成

例如：

public class DependecyInversion {public static void main(String[] args) {//客户端无需改变Person person = new Person();person.receive(new Email());person.receive(new WeiXin());}}//通过接口传递实现依赖
//定义接口
interface IReceiver {public String getInfo();
}class Email implements IReceiver {public String getInfo() {return "电子邮件信息: hello,world";}
}//增加微信
class WeiXin implements IReceiver {public String getInfo() {return "微信信息: hello,ok";}
}

遇事不决加一层…

依赖倒转有三种实现方式，它们分别是：

1. 接口传递
2. 构造方法传递
3. setter方法传递

依赖倒转原则的注意事项和细节：

1. 低层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好；
2. 变量的声明类型尽量是抽象类或接口，这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化；
3. 继承时遵循里氏替换原则；

里氏替换原则（LSP）

继承性的思考和说明：

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

定义：

• 里氏替换原则(Liskov Substitution Principle)通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能，即子类尽量不要重写父类的方法；
• 里氏代换原则告诉我们，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象；
• 里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象；
• 里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合、组合、依赖来解决问题。

例子：

// A类
class A {// 返回两个数的差public int func1(int num1, int num2) {return num1 - num2;}
}// B类继承了A
// 增加了一个新功能：完成两个数相加,然后和9求和
class B extends A {//这里，重写了A类的方法, 可能是无意识public int func1(int a, int b) {return a + b;}public int func2(int a, int b) {return func1(a, b) + 9;}
}public class Liskov {public static void main(String[] args) {A a = new A();System.out.println("11-3=" + a.func1(11, 3));System.out.println("1-8=" + a.func1(1, 8));System.out.println("-----------------------");B b = new B();System.out.println("11-3=" + b.func1(11, 3));//这里本意是求出11-3System.out.println("1-8=" + b.func1(1, 8));// 1-8System.out.println("11+3+9=" + b.func2(11, 3));}
}

运行结果：

开闭原则（OCP）

基本介绍

1. 开闭原则（Open Closed Principle）是编程中最基础、最重要的设计原则
2. 一个软件实体如类，模块和函数应该对扩展开放(对提供方)，对修改关闭(对使用方)。用抽象构建框架，用实现扩展细节。
3. 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
4. 编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。

简单地来说就是一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。

例子：
比如公司现在要弄一个打折活动，小说类的书籍要打折，按照开闭原则我们应该扩展来实现，而不应该修改原有代码，所以我们设置一个打折子类来继承小说类，在子类中实现打折方法，也遵循了里式替换原则【嘻嘻】。

//书籍接口类
interface IBook{String getName();double getPrice();String getAuthor();
}//小说子类
class NovelBook implements IBook{String name;double price;String author;public NovelBook(String name,int price,String author){this.name = name;this.price = price;this.author = author;}public String getAuthor(){return this.author;}public String getName(){return this.name;}public double getPrice(){return this.price;}
}//小说打折子类
class OffNovelBook extends NovelBook{public OffNovelBook(String name,int price,String author){super(name,price,author);}//当价格大于40，就打8析，其他价格就打9析public double getDiscountPrice(){if(this.price > 40){return this.price * 0.8;}else{return this.price * 0.9;}}
}public class OpenClosedPrinciple {public static void main(String[] args){OffNovelBook offNovelBook = new OffNovelBook("笑傲江湖",100,"金庸");System.out.println("书籍名字："+offNovelBook.getName()+",书籍作者："+offNovelBook.getAuthor()+",书籍价格："+offNovelBook.getPrice());System.out.println("打折后的价格："+offNovelBook.getDiscountPrice());}
}

运行结果：

迪米特法则（DP）

基本介绍

1. 一个对象应该对其他对象保持最少的了解。类与类关系越密切，耦合度越大
2. 迪米特法则(Demeter Principle)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的 public 方法，不对外泄露任何信息
3. 迪米特法则还有个更简单的定义：只与直接的朋友通信
4. 直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合等。其中，我们称出现在成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。
5. 迪米特法则初衷在于降低类之间的耦合。由于每个类尽量减少对其它类的依赖，因此。很容易使得系统的功能模块独立，相互之间不存在(或很少有)依赖关系。

迪米特法则大概可以理解保持神秘感（朋友对你了解得不多）+只和朋友来往，以降低类之间的耦合，怎么感觉这么像特工。。。

合成复用原则

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

PS：也可以到我的个人博客查看更多内容
个人博客地址：小关同学的博客