设计模式简述

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

设计模式的目的：

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

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

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

设计模式的原则

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

单一职责原则
接口隔离原则
依赖倒转（倒置）原则
里氏替换原则
开闭原则
迪米特法则
合成复用原则

单一职责原则（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)是指：

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

例如：

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";}
}

遇事不决加一层…

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

接口传递
构造方法传递
setter方法传递

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

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

里氏替换原则（LSP）

继承性的思考和说明：

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

定义：

里氏替换原则(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）

基本介绍

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

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

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

//书籍接口类
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）

基本介绍

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

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

合成复用原则

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

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

设计模式学习1：设计模式简述和设计模式原则相关推荐

设计模式学习（一）：设计原则
设计模式学习(一):设计原则作者:Grey 原文地址: 博客园:设计模式学习(一):设计原则 CSDN:设计模式学习(一):设计原则开闭原则对扩展开放,对修改关闭,降低维护带来的新风险先看一个 ...
设计模式学习总结（一）——设计原则与UML统一建模语言
目录一.概要 1.1.设计模式定义 1.2.设计模式分类 1.3.设计模式书籍二.UML统一建模语言 2.1.UML分类 2.2.类图 2.2.1.关联 2.2.2.聚合/组合 2.2.3.依赖 ...
设计模式学习笔记七：常用设计模式原则总结
前面学习了一部分创建型模式,发现了一个比设计模式更重要的东西:设计模式原则.对于设计模式来说,为什么这个模式要这样解决这个问题,而另一个模式要那样,它们背后都遵循的就是永恒的设计原则.可以说,设计原则 ...
Java设计模式学习总结（1）——设计模式简介
一.设计模式简介设计模式(Design pattern)代表了最佳的实践,通常被有经验的面向对象的软件开发人员所采用.设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案.这些解决方案是众 ...
设计模式学习笔记十七（迭代器设计模式）
1.概述定义: 提供一个对象来顺序访问聚合对象中的一系列数据,而不暴露聚合对象的内部表示. 2.结构迭代器模式主要包含以下角色: 抽象聚合(Aggregate)角色:定义存储.添加.删除聚合元素以 ...
36设计模式学习笔记
设计模式学习笔记文章目录 0.设计模式简介 1.单例模式 2.工厂方法 3.抽象工厂 4.责任链模式 5.模板方法 ok 一.模板方法简介二.模式的定义和特点三.模式的结构和实现四.什么是模板 ...
设计模式学习笔记清单
设计模式学习笔记清单关于设计模式许多人已经耳熟能详,这段时间结合李建忠的教学视频以及大量网络资料,把这部分过了一遍,整理出学习笔记,而真正的深入学习和理解只能在具体的开发环境中日积月累. ...
设计模式学习笔记——解释器(Interpreter)模式
设计模式学习笔记--解释器(Interpreter)模式 @(设计模式)[设计模式, 解释器模式, Interpreter] 设计模式学习笔记解释器Interpreter模式基本介绍解释器案例类 ...
设计模式学习笔记——命令(Command)模式
设计模式学习笔记--命令(Command)模式 @(设计模式)[设计模式, 命令模式, command] 设计模式学习笔记命令Command模式基本介绍命令案例类图实现代码 Command接口 ...
设计模式学习笔记——代理(Proxy)模式
设计模式学习笔记--代理(Proxy)模式 @(设计模式)[设计模式, 代理模式, proxy] 设计模式学习笔记代理Proxy模式基本介绍代理案例类图实现代码 Printable接口 Pri ...

设计模式学习1：设计模式简述和设计模式原则

设计模式简述

设计模式的原则

单一职责原则（SRP）

接口隔离原则（ISP）

依赖倒转原则（DIP）

里氏替换原则（LSP）

开闭原则（OCP）

迪米特法则（DP）

合成复用原则

设计模式学习1：设计模式简述和设计模式原则相关推荐

最新文章

热门文章