设计模式大集合
Posted 尚墨1111
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了设计模式大集合相关的知识,希望对你有一定的参考价值。
1 概述
1.1 意义:
设计模式
是前人工作的总结和提炼。通常,被人们广泛流传的设计模式都是对某一特定问题的成熟的解决方案。如果能合理地使用设计模式,不仅能使系统更容易地被他人理解,同时也能使系统拥有更加合理的结构。项目做的非常大,非常复杂的时候,仍然能让你能掌控这些代码,不会让他们乱成一团。
设计模式可以让你知道在某些场景下如何来设计出适合场景的架子,因为经验不丰富,大部分程序员写的代码的可维护性是非常差的,基本上只是实现了功能,没有做其他的考虑,比如以后要加新功能,目前写的程序改怎么改,或者类之间的关系非常复杂,不熟悉代码的人,根本不能开发等问题。
1.2 要求:
学完设计模式,再看各种框架的源码,感受别人代码的美感,与实际体会设计模式的使用模式。
在系统的学习设计模式之后,我们需要达到3个层次:
- 能在白纸上画出所有的模式结构和时序图;
- 能用代码实现;如果模式的代码都没有实现过,是用不出来的;即所谓,看得懂,不会用;
- 灵活应用到工作中的项目中;
1.3 UML结构
类的继承结构表现在UML中为:泛化(generalize)与实现(realize):
泛化表示继承非抽象类:宝马——小汽车
实现表示继承抽象类:小汽车——车
聚合关系:表示整体由部分构成的语义;例如一个部门由多个员工组成;整体不存在了,部分仍然存在
组合关系:整体由部分构成的语义;比如公司由多个部门组成;如果整体不存在了,则部分也不存在了
关联关系:不同类的对象之间的结构关系;学生和学校就是一种关联关系;
依赖关系:描述一个对象在运行期间会用到另一个对象的关系;
1.4 GoF23 总览
创建型模式分为以下5种:
- 单例(Singleton)模式:某个类只能生成一个实例,该类提供了一个全局访问点供外部获取该实例,其拓展是有限多例模式。
- 原型(Prototype)模式:将一个对象作为原型,通过对其进行复制而克隆出多个和原型类似的新实例。
- 工厂方法(Factory Method)模式:定义一个用于创建产品的接口,由子类决定生产什么产品。
- 抽象工厂(Abstract Factory)模式:提供一个创建产品族的接口,其每个子类可以生产一系列相关的产品。
- 建造者(Builder)模式:将一个复杂对象分解成多个相对简单的部分,然后根据不同需要分别创建它们,最后构建成该复杂对象。
结构型模式分为以下 7 种:
- 代理(Proxy)模式:为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象,从而限制、增强或修改该对象的一些特性。
- 适配器(Adapter)模式:将一个类的接口转换成客户希望的另外一个接口,使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
- 桥接(Bridge)模式:将抽象与实现分离,使它们可以独立变化。它是用组合关系代替继承关系来实现的,从而降低了抽象和实现这两个可变维度的耦合度。
- 装饰(Decorator)模式:动态地给对象增加一些职责,即增加其额外的功能。
- 外观(Facade)模式:为多个复杂的子系统提供一个一致的接口,使这些子系统更加容易被访问。
- 享元(Flyweight)模式:运用共享技术来有效地支持大量细粒度对象的复用。
- 组合(Composite)模式:将对象组合成树状层次结构,使用户对单个对象和组合对象具有一致的访问性。
行为型模式 11 种:
- 模板方法(Template Method)模式:定义一个操作中的算法骨架,将算法的一些步骤延迟到子类中,使得子类在可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
- 策略(Strategy)模式:定义了一系列算法,并将每个算法封装起来,使它们可以相互替换,且算法的改变不会影响使用算法的客户。
- 命令(Command)模式:将一个请求封装为一个对象,使发出请求的责任和执行请求的责任分割开。
- 职责链(Chain of Responsibility)模式:把请求从链中的一个对象传到下一个对象,直到请求被响应为止。通过这种方式去除对象之间的耦合。
- 状态(State)模式:允许一个对象在其内部状态发生改变时改变其行为能力。
- 观察者(Observer)模式:多个对象间存在一对多关系,当一个对象发生改变时,把这种改变通知给其他多个对象,从而影响其他对象的行为。
- 中介者(Mediator)模式:定义一个中介对象来简化原有对象之间的交互关系,降低系统中对象间的耦合度,使原有对象之间不必相互了解。
- 迭代器(Iterator)模式:提供一种方法来顺序访问聚合对象中的一系列数据,而不暴露聚合对象的内部表示。
- 访问者(Visitor)模式:在不改变集合元素的前提下,为一个集合中的每个元素提供多种访问方式,即每个元素有多个访问者对象访问。
- 备忘录(Memento)模式:在不破坏封装性的前提下,获取并保存一个对象的内部状态,以便以后恢复它。
- 解释器(Interpreter)模式:提供如何定义语言的文法,以及对语言句子的解释方法,即解释器。
1.6 设计模式源码分析(!!!)
设计模式学习参考:
源码使用设计模式分析:
2 设计模式的七大原则
我们先要写出低耦合高内聚的代码,在java中需要遵循如下原则:
- 模块间的依赖通过抽象类或接口发生,实现类之间的依赖关系也是通过抽象类或接口产生(实现类之间不应发生直接的依赖关系),降低系统的耦合性
- 接口或抽象不依赖于实现类,但实现类依赖接口或抽象类,实现类对系统需要的功能具体实现,提高类的内聚程度
总结:降低对象之间的耦合,增加程序的可复用性、可扩展性和可维护性。
设计原则 | 一句话归纳 | 目的 |
---|---|---|
开闭原则 | 对扩展开放,对修改关闭 | 降低维护带来的新风险 |
依赖倒置原则 | 高层不应该依赖低层,要面向接口编程 | 更利于代码结构的升级扩展 |
单一职责原则 | 一个类只干一件事,实现类要单一 | 便于理解,提高代码的可读性 |
接口隔离原则 | 一个接口只干一件事,接口要精简单一 | 功能解耦,高聚合、低耦合 |
迪米特法则 | 只和朋友交流,不和陌生人说话 | 减少代码臃肿 |
里氏替换原则 | 不要破坏继承体系,子类重写方法功能发生改变,不应该影响父类方法的含义 | 防止继承泛滥 |
合成复用原则 | 尽量使用组合或者聚合关系实现代码复用,少使用继承 | 降低代码耦合 |
2.1 开闭原则
开闭原则(Open Close Principle)就是说对扩展开放,对修改关闭。在程序需要进行拓展的时候,不能去修改原有的代码,而是要扩展原有代码,实现一个热插拔的效果。所以一句话概括就是:使程序的扩展性好,易于维护和升级。
2.2 单一职责原则
每个类应该实现单一的职责,如若不然,就应该把类拆分。
2.3 里氏替换原则
里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说,任何基类可以出现的地方,子类一定可以出现。 LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范。
2.4 依赖倒置原则
依赖倒转原则(Dependence Inversion Principle)是开闭原则的基础,具体内容:面向接口编程,依赖于抽象而不依赖于具体。写代码时用到具体类时,不与具体类交互,而与具体类的上层接口交互。
// “高层模块不应该依赖于低层模块,二者都应该依赖于抽象。”这一原则在分层架构模式中,得到了淋漓尽致地运用。
public class CarController{
//通过依赖注入来指定实现类,而这里只写抽象类。——依赖于抽象而不依赖于具体
CarService carService;
public void run(){
carService.run();
}
}
2.5 接口隔离原则
接口隔离原则(Interface Segregation Principle),这个原则的意思是:每个接口中不存在子类用不到却必须实现的方法,如果不然,就要将接口拆分。使用多个隔离的接口,比使用单个接口(多个接口方法集合到一个的接口)要好。
在具体应用接口隔离原则时,应该根据以下几个规则来衡量。
- 接口尽量小,但是要有限度。一个接口只服务于一个子模块或业务逻辑。
- 为依赖接口的类定制服务。只提供调用者需要的方法,屏蔽不需要的方法
【例1】学生成绩管理程序。
分析:学生成绩管理程序一般包含插入成绩、删除成绩、修改成绩、计算总分、计算均分、打印成绩信息、査询成绩信息等功能,如果将这些功能全部放到一个接口中显然不太合理,正确的做法是将它们分别放在输入模块、统计模块和打印模块等 3 个模块中
2.6 迪米特法则
迪米特法则(最少知道原则)(Demeter Principle),就是说:一个类对自己依赖的类知道的越少越好。也就是说无论被依赖的类多么复杂,都应该将逻辑封装在方法的内部,通过public方法提供给外部。这样当被依赖的类变化时,才能最小的影响该类。
最少知道原则的另一个表达方式是:只与直接的朋友通信。类之间只要有耦合关系,就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。比如代理模式、中介者模式。
【例1】明星与经纪人的关系实例。
分析:明星由于全身心投入艺术,所以许多日常事务由经纪人负责处理,如与粉丝的见面会,与媒体公司的业务洽淡等。这里的经纪人是明星的朋友,而粉丝和媒体公司是陌生人,所以适合使用迪米特法则
2.7 合成复用原则
合成复用原则(Composite Reuse Principle)原则是尽量首先使用合成/聚合的方式,而不是使用继承。比如桥接模式。
通常类的复用可以分为继承和合成,继承复用虽然简单,但是存在很大的缺点:
(1)耦合度高,父类代码的修改会影响到子类,不利于代码的维护。
(2)破坏了类的封装性,因为继承会将父类的实现细节暴露给子类,所以又叫做 “白箱” 复用。
(3)限制了复用的灵活性,从父类继承来的实现是静态的,在运行期是无法改变的
合成复用是将已有的对象作为新对象的成员对象来实现,新对象调用已有对象的功能,达到复用:
(1)不会破坏封装性,因为新对象只能调用已有对象暴露出来的方法,所以又叫做 “黑箱” 复用
(2)耦合度低,已有对象的变化对新对象的影响较小,可以在新对象的中,根据需要调用已有对象的一些操作。
(3)复用的灵活性高,可以在代码的运行中,动态选择相同类型的其他具体类。
可以看出用继承关系实现会产生很多子类,而且增加新的“动力源”或者增加新的“颜色”都要修改源代码,这违背了开闭原则,显然不可取。但如果改用组合关系实现就能很好地解决以上问题。
3 创建型模式:
创建型模式的主要关注点是“怎样创建对象?”,它的主要特点是“将对象的创建与使用分离”。这样可以降低系统的耦合度,使用者不需要关注对象的创建细节,对象的创建由相关的工厂来完成。就像我们去商场购买商品时,不需要知道商品是怎么生产出来一样,因为它们由专门的厂商生产。
3.1 工厂方法模式
工厂模式的三种形态
- 简单工厂(Simple Factory)不属于23种设计模式。
- 工厂方法(Factory Method)
- 抽象工厂(Abstract Factory)
3.1.1 简单工厂模式
又称为静态工厂方法(Static Factory Method)模式。在简单工厂模式中,可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。
就是通过传入不同的参数,返回不同的实例。传入 A 返回白酒,传入 B 返回红酒
缺点:将对象的创建交给专门的工厂类负责,但是其最大的缺点在于工厂类不够灵活,增加新的具体产品需要修改工厂类的判断逻辑代码,而且产品较多时,工厂方法代码将会非常复杂,这一点与开闭原则是相违背的。
interface Animal{
void run(String name );
}
//简单工厂模式
class AnimalFactory implements Animal{
@Override
public void run(String name) {
if(name.equals("dog")){
System.out.println("ddaada");
}
if(name.equals("pig")){
System.out.println("jiajia");
}
}
}
实际应用:
1、JDK类库如工具类java.text.DateFormat,它用于格式化一个本地日期或者时间。
public final static DateFormat getDateInstance();
public final static DateFormat getDateInstance(int style);
public final static DateFormat getDateInstance(int style,Locale locale);
2、Java加密技术
获取不同加密算法的密钥生成器:
KeyGenerator keyGen=KeyGenerator.getInstance("DESede");
创建密码器:
Cipher cp=Cipher.getInstance("DESede");
3.1.2 工厂方法模式。
使用了面向对象的多态性,将产品类的实例化操作延迟到工厂子类中完成,即通过工厂子类来确定究竟应该实例化哪一个具体产品类。这个核心类仅仅负责给出具体工厂必须实现的接口,而不负责哪一个产品类被实例化这种细节,这使得工厂方法模式可以允许系统在不修改工厂角色的情况下引进新产品。
针对不同的产品(图片读取器)
提供不同的工厂。
//产品
interface ImgReader{
void read();
}
//不同的具体产品
class PngImgReader implements ImgReader{
@Override
public void read() {
System.out.println("png图片格式阅读器");
}
}
class JpgImgReader implements ImgReader{
@Override
public void read() {
System.out.println("jpg图片阅读器");
}
}
//产品抽象工厂
interface ImgReaderFactory{
ImgReader creat();
}
//针对不同的产品有不同的实现工厂
class PngImgReaderFactory implements ImgReaderFactory{
@Override
public ImgReader creat() {
System.out.println("实例化png图片阅读器");
return new PngImgReader();
}
}
class JpgImgReaderFactory implements ImgReaderFactory{
@Override
public ImgReader creat() {
System.out.println("实例化jpg图片阅读器");
return new JpgImgReader();
}
}
@Test
public void test(){
//1.创建具体工厂
ImgReaderFactory pngImgReaderFactory = new PngImgReaderFactory();
//2.具体化实例
ImgReader reader = pngImgReaderFactory.creat();
reader.read();
}
缺点: 每次需要编写新的对象和对象工厂类
,随业务发展,一定程度上增加了系统复杂度
3.2 抽象工厂模式
提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们具体的类。工厂方法模式只生产一个等级的产品,而抽象工厂模式可生产多个等级的产品。
【例1】用抽象工厂模式设计农场类。
分析:农场中除了像畜牧场一样可以养动物,还可以培养植物,如养马、养牛、种菜、种水果等,所以本实例比前面介绍的畜牧场类复杂,必须用抽象工厂模式来实现。
3.3 建造者模式
建造者(Builder)模式的定义:指将一个复杂对象的构造与它的表示分离,使同样的构建过程可以创建不同的表示,这样的设计模式被称为建造者模式。它是将一个复杂的对象分解为多个简单的对象,然后一步一步构建而成。它将变与不变相分离,即产品的组成部分是不变的,但每一部分是可以灵活选择的。
建造者模式
让我们写的代码更具可读性,可理解为建立复杂的物体。它往往是实现一个连贯的操作,从而更加直观。有时候构建一个复杂的对象,需要经过好几步的处理,比如常用的StringBuffer、StringBuilder、以及Swagger(一种接口文档)
,都是以这种模式构建对象的
如果将抽象工厂模式看成 汽车配件生产工厂 ,生产一个产品族的产品,那么建造者模式就是一个 汽车组装工厂 ,通过对部件的组装可以返回一辆完整的汽车。建造者
是在最后的一步返回对象,而对于抽象工厂来说,对象是立即返回的。
实例:KFC套餐
建造者模式可以用于描述KFC如何创建套餐:套餐是一个复杂对象,它一般包含主食(如汉堡、鸡肉卷等)和饮料(如果汁、 可乐等)等组成部分,不同的套餐有不同的组成部分,而KFC的服务员可以根据顾客的要求,一步一步装配这些组成部分,构造一份完整的套餐,然后返回给顾客。
如果你发现自己在一个情况下,你不断添加新参数的构造函数,使得代码变得容易出错,很难读,也许可以考虑使用一个Builder
重构你的代码。当构造函数的参数太多、类型极容易混淆是可以构建者模式
public class Summoner {
private String name;
private String type;
private String innate;
private Summoner(Builder builder) {
this.name = builder.name;
this.type = builder.type;
this.innate = builder.innate;
}
//建造者内部类
protected static class Builder {
private String name;
private String type;
private String innate;
protected Builder name(String name) {
this.name = name;
return this;
}
protected Builder type(String type) {
this.type = type;
return this;
}
protected Builder innate(String innate) {
this.innate = innate;
return this;
}
protected Summoner build() { return new Summoner(this);}
}
}
public class BuilderDemo {
public static void main(String[] args) {
Summoner monkey = new Summoner.Builder().name("孙悟空").type("上单").innate("战争雷霆").build();
System.out.println(monkey.toString());
}
}
3.4 单例模式
通常,普通类的构造函数是公有的,外部类可以通过“new 构造函数()”来生成多个实例。但是,如果将类的构造函数设为私有的,外部类就无法调用该构造函数,也就无法生成多个实例。这时该类自身必须定义一个静态私有实例,并向外提供一个静态的公有函数用于创建或获取该静态私有实例。
单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例,这个类称为单例类,它提供全局访问的方法。只有一个实例很重要,例如,一个系统中可以存在多个打印任务,但是只能有一个正在工作的任务;
单例模式的要点有三个:
一是某个类只能有一个实例;
二是它必须自行创建这个实例;
三是它必须自行向整个系统提供这个实例。
Java中,单例模式
主要分:懒汉式单例、DCL饿汉式模式(双重校验锁)、静态内部类、懒汉模式
//饿汉模式
public class HungrySingleton {
private static final HungrySingleton instance = new HungrySingleton();
private HungrySingleton() {
}
public static HungrySingleton getInstance() {
return instance;
}
}
//DCL懒汉
private volatile static LazyLoader lazyLoader;//防止指令重拍
public static LazyLoader getInstance() {
if (lazyLoader == null) {
synchronized (LazyLoader.class) {
if (lazyLoader == null) {
lazyLoader = new LazyLoader();
}
}
}
return lazyLoader;
}
//静态内部类
public class Holder {
private Holder() {
}
public static Holder getInstance() {
return InnerClass.holder;
}
private static class InnerClass {
private static final Holder holder = new Holder();
}
}
//枚举类
public enum EnumSingleton {
INSTANCE;
public EnumSingleton getInstance(){
return INSTANCE;
}
}
3.5 原型模式
复制现有的对象实例来创建新的对象实例。
原型模式的优点:
- Java 自带的原型模式基于内存二进制流的复制,在性能上比直接 new 一个对象更加优良。
- 可以使用深克隆方式保存对象的状态,使用原型模式将对象复制一份,并将其状态保存起来,简化了创建对象的过程,以便在需要的时候使用(例如恢复到历史某一状态),可辅助实现撤销操作。
缺点:
- 通过内存拷贝的方式构建出来的,会忽略构造函数限制
- 需要注意
深拷贝
和浅拷贝
,默认Cloneable
是浅拷贝
,只拷贝当前对象而不会拷贝引用对象,除非自己实现深拷贝
- 与
单例模式
冲突,clone
是直接通过内存拷贝
的方式,绕过构造方法
实现Cloneable接口:
Cloneable接口的作用是在运行时通知虚拟机可以安全地在实现了此接口的类上使用clone方法。在java虚拟机中,只有实现了这个接口的类才可以被拷贝,否则在运行时会抛出CloneNotSupportedException异常。
重写Object类中的clone方法:
Java中,所有类的父类都是Object类,Object类中有一个clone方法,作用是返回对象的一个拷贝,但是其作用域protected类型的,一般的类无法调用,因此,原型类需要将clone方法的作用域修改为public类型。
适用场景
- 常用在初始化步骤繁琐,资源耗损严重的对象
4 结构型模式
结构型模式描述如何将类或对象按某种布局组成更大的结构,就像搭积木,可以通过简单积木的组合形成复杂的、功能更为强大的结构。它分为类结构型模式和对象结构型模式,前者采用继承机制来组织接口和类,后者釆用组合或聚合来组合对象。
结构型模式可以分为类结构型模式和对象结构型模式,由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象结构型模式比类结构型模式具有更大的灵活性:
-
类结构型模式中一般只存在继承关系和实现关系。
-
对象结构型模式关心类与对象的组合,在系统中尽量使用关联关系(不同类的对象之间的结构关系)来替代继承关系,大部分结构型模式都是对象结构型模式。
4.1 适配器模式
在现实生活中,经常出现两个对象因接口不兼容而不能在一起工作的实例,这时需要第三者进行适配。例如,讲中文的人同讲英文的人对话时需要一个翻译,用直流电的笔记本电脑接交流电源时需要一个电源适配器,类似type-c
的转接口。在软件开发中采用类似于电源适配器的设计和编码技巧被称为适配器模式。
在适配器模式中可以定义一个包装类,包装不兼容接口的对象,这个包装类指的就是适配器(Adapter),它所包装的对象就是适配者(Adaptee),其别名为包装器(Wrapper),即被适配的类。适配器提供客户类需要的接口,适配器的实现就是把客户类的请求转化为对适配者的相应接口的调用
使用场景:相当于外面包一层
- 系统需要使用现有的类,而这些类的接口不符合系统的需要。
- 想要建立一个可以重复使用的类,用于与一些彼此之间没有太大关联的一些类,包括一些可能在将来引进的类一起工作。
类适配器:
Java I/O 库大量使用了适配器模式,如
ByteArrayInputStream
是一个适配器类,它继承了InputStream
的接口,并且封装了一个 byte 数组。换言之,它将一个 byte 数组的接口适配成 InputStream 流处理器的接口。Advice(通知)的类型有:BeforeAdvice、AfterReturningAdvice、ThrowSadvice 等。每个类型 Advice(通知)都有对应的拦截器,MethodBeforeAdviceInterceptor、AfterReturningAdviceInterceptor、ThrowsAdviceInterceptor。Spring 需要将每个 Advice(通知)都封装成对应的拦截器类型,返回给容器,所以需要使用适配器模式对 Advice 进行转换。
对象适配器:
//标准接口
interface Target{
void connect();
}
//特殊接口
class M5DataLine implements Target{
@Override
public void connect() {
System.out.println("M5连接器");
}
}
// 创建适配器类,实现标准接口
class DataLineAdapter implements Target{
private Target target;
public DataLineAdapter(Target target) {
this.target = target;
}
//将这个调用委托给实现新接口的对象来处理
@Override
public void connect() {
System.out.println("转接口");
target.connect();
}
}
4.2 桥接模式
可以理解成原来由继承来实现不同功能的方式,这种紧耦合,及对于多个维度指数型增长的情况,利用桥接的方式松耦合,将抽象部分与它的实现部分分离,使它们都可以独立地变化。
桥接模式将继承关系转换为关联关系(不同类的对象之间的结构关系,内部属性),从而降低了类与类之间的耦合,减少了代码编写量。因为继承复用破坏包装,父类发生改变,则子类也要发生相应的改变,这就直接导致了类之间的紧耦合,不利于类的扩展、复用、维护。
//抽象部分与实现部分分离
interface Car{
void run();
}
//将继承改为不同对象之间的结构关系
abstract class AbstractRoad{
protected Car car;
public AbstractRoad(Car car) { this.car = car; }
public abstract void run();
}
//抽象类的分别实现部分,汽车类
class BusCar implements Car{
@Override
public void run() { System.out.println("公共汽车"); }
}
class smallCar implements Car{
@Override
public void run() { System.out.println("小汽车"); }
}
//道路类
class SpeedRoad extends AbstractRoad{
public SpeedRoad(Car car) { super(car); }
@Override
public void run() {
System.out.println("在高速公路");
car.run();
}
}
class StreetRoad extends AbstractRoad{
public StreetRoad(Car car以上是关于设计模式大集合的主要内容,如果未能解决你的问题,请参考以下文章