Java设计模式最全总结(完整代码+笔记)

完整带图代码+笔记请访问:https://github.com/geekerstar/design-pattern ,欢迎Star!

七大设计原则

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

设计模式

设计模式-创建型模式

工厂方法模式、抽象工厂模式、建造者模式、单例模式、原型模式

设计模式-结构型模式

适配器模式、装饰着模式、代理模式、外观模式、桥接模式、组合模式、享元模式

设计模式-行为型模式

策略模式、观察者模式、责任链模式、备忘录模式、模板方法模式、迭代器模式、中介者模式、命令模式、访问者模式、解释器模式、状态模式

UML特点

  • UML是一种开放的方法
  • 用于说明、可视化、构建和编写一个正在开放的面向对象的、软件密集系统的制品的开放方法
  • UML展现了一系列最佳工程实践,这些最佳实践在对大规模,复杂系统进行建模方面,特别是在软件架构层次已经被验证有效

UML2.2分类

UML2.2一共定义了14种图示,分类如下
– 结构式图形:强调的是系统式的建模
– 行为式图形,强调系统模型中触发的事件
– 交互式图形:属于【行为式】图形的子集合,强调系统模型中资料流程

结构式图形

  • 静态图(类图,对象图,包图)
  • 实现图(组件图,部署图)
  • 剖面图
  • 符合结构

行为式图形

  • 活动图
  • 状态图
  • 用例图

交互式图形

  • 通信图
  • 交互概述图(UML2.0)
  • 时序图(UML2.0)
  • 时间图(UML2.0)

UML类图

  • class Diagram:用于表示类、接口、实例之间相互的静态关系
  • 虽然名字叫类图,但类图中并不只有类

记忆技巧

  • UML箭头方向:从子类指向父类
  • 提示:可能会认为子类是以父类为基础的,箭头应从父类指向子类

记忆技巧-箭头方向

  • 定义子类时需要通过extends关键字指定父类
  • 子类一定是指导父类定义的,但父类并不知道子类的定义
  • 只有知道对方信息时才能指向对方
  • 所以箭头方向是从子类指向父类

Java设计模式最全总结(完整代码+笔记)

记忆技巧-实线-继承|虚线-实现

  • 空心三角箭头:继承或实现
  • 实线-继承,is a 关系,扩展目的,不虚,很结实
  • 虚线-实现,虚线代表“虚”无实体

Java设计模式最全总结(完整代码+笔记)

Java设计模式最全总结(完整代码+笔记)

记忆技巧-实线-关联|虚线-依赖

  • 虚线-依赖关系:临时用一下,若即若离,虚无缥缈,若有若无
  • 表示一种使用关系,一个类需要借助另一个类来实现功能
  • 一般是一个类使用另一个类作为参数使用,或作为返回值

记忆技巧-实现-关联|虚线-依赖

  • 实线-关联关系:关系稳定,实打实的关系,铁哥们
  • 表示一个类对象和另一个类对象有关联
  • 通常是一个类中有另一个类对象作为属性

记忆技巧-空心菱形-聚合|实心菱形-组合

  • 菱形就是一个盛东西的器皿(例如盘子)
  • 聚合:代表空器皿里可以放很多相同东西,聚在一起(箭头方向所指向的类
  • 组合:代表满器皿里已经有实体结构的存在,生死与共

Java设计模式最全总结(完整代码+笔记)

Java设计模式最全总结(完整代码+笔记)

记忆技巧-空心菱形-聚合

  • 整体和局部的关系,两者有着独立的生命周期,是has a的关系
  • 弱关系
  • 消极的词:弱-空

记忆技巧-实心菱形-组合

  • 整体与局部的关系,和聚合的关系相比,关系更加强烈,两者有相同的生命周期,contains-a的关系
  • 强关系
  • 积极的词:强-满

记忆技巧-实心菱形-组合

常见数字表达及含义,假设有A类和B类,数字标记在A类侧
– 0..1:0或1个实例
– 0..:0或多个实例
– 1..1:1个实例
– 1 只能有一个实例
– 1..
:至少有一个实例

UML时序图

  • Sequence Diagram:是显示对象之间交互的图,这些对象是按时间顺序排列的
  • 时序图中包括的建模元素主要有:对象(Actor)、生命线(LifeLine)、控制焦点(Focus of control)、消息(Message)等

Java设计模式最全总结(完整代码+笔记)

Java设计模式最全总结(完整代码+笔记)

Java设计模式最全总结(完整代码+笔记)Java设计模式最全总结(完整代码+笔记)

七大设计原则

开闭原则

  • 定义:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。
  • 用抽象构建框架,用实现扩展细节
  • 优点:提高软件系统的可复用性及可维护性

依赖倒置原则

  • 定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象
  • 抽象不应该依赖细节,细节应该依赖抽象
  • 针对接口编程,不要针对实现编程
  • 优点:可以减少类间的耦合性,提高系统稳定性,提高代码可读性和可维护性,可降低修改程序所造成的风险

单一职责原则

  • 定义:不要存在多于一个导致类变更的原因
  • 一个类/接口/方法只负责一项职责
  • 优点:降低类的复杂度,提高类的可读性,提高系统的可维护性,降低变更引起的风险

接口隔离原则

  • 定义:用多个专门的接口,而不使用单一的总接口,客户端不应该依赖它不需要的接口
  • 一个类对一个类的依赖应该建立在最小的接口上
  • 建立单一接口,不要建立庞大臃肿的接口
  • 尽量细化接口,接口中的方法尽量少
  • 注意点:注意适度原则,一定要适度
  • 优点:符合我们常说的高内聚低耦合的设计思想,从而使得类具有很好的可读性,可扩展性和可维护性。

迪米特原则

  • 定义:一个对象应该对其他对象保持最少的了解,又叫最小知道原则。
  • 尽量降低类与类之间的耦合。
  • 优点:降低类之间的耦合。
  • 强调只和朋友交流,不和陌生人说话。
  • 朋友:出现在成员变量,方法的输入,输出参数中的类称为成员朋友类,而出现在方法体内部的类不属于朋友。

里氏替换原则

  • 定义:如果对每一个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都替换成o2时,程序p的行为没有发生变化,那么类型T2是类型T1的子类型。
  • 定义扩展:一个软件实体如果适用一个父类的话,那么一定适用于其子类,所有引用父类的地方必须能透明地适用其子类的对象,子类对象能够替换父类对象,而程序逻辑不变。
  • 引申意义:子类可以扩展父类的功能,但不能改变父类原有的功能。
  • 含义1:子类可以实现父类的抽象方法,但不能覆盖父类的非 抽闲方法。
  • 含义2:子类中可以增加自己特有的方法。
  • 含义3:当子类的方法重载父类的方法时,方法的前置条件(即方法的输入/入参)要比父类方法的输入参数更宽松。
  • 含义4:当子类的方法实现父类的方法时(重写/重载或实现抽象方法),方法的后置条件(即方法的输出/返回值)要比父类更严格或相等。
  • 优点1:约束继承泛滥,开闭原则的一种体现。
  • 优点2:加强程序的健壮性,同时变更时也可以做到非常好的兼容性,提高程序的维护性,扩展性。降低需求变更时引入的风险。

合成(组合)/聚合复用原则

  • 定义:尽量使用对象组合/聚合,而不是继承关系达到软件复用的目的
  • 聚合has-A和组合contains-A
  • 优点:可以使系统更加灵活,降低类与类之间的耦合度,一个类的变化对其他类造成的影响相对较少。
  • 何时使用合成/聚合、继承
  • 聚合has-A,组合contains-A 继承is-A

创建型设计模式

简单工厂

  • 定义:由一个工厂对象决定创建出哪一种产品类的实例
  • 类型:创建型,但不属于GOF23种设计模式
  • 适用场景:工厂类负责创建的对象比较少;客户端(应用层)只知道传入工厂类的参数,对于如何创建对象(逻辑)不关心
  • 优点:只需要传入一个正确的参数,就可以获取你所需要的对象而无需知道其创建细节。
  • 缺点:工程类的职责相对过重,增加新的产品需要修改工厂类的判断逻辑,违背开闭原则。

工厂方法

  • 定义:定义一个创建对象的接口,但让实现这个接口的类来决定实例化哪个类,工厂方法让类的实例化推迟到子类中进行
  • 类型:创建型
  • 适用场景:创建对象需要大量重复的代码;客户端(应用层)不依赖于产品类实例如何被创建、实现等细节;一个类通过其子类来指定创建哪个对象。
  • 优点:用户只需要关心所需产品对应的工厂,无须关心创建细节;加入新产品符合开闭原则,提高可扩展性。
  • 缺点:类的个数容易过多,增加复杂度;增加了系统的抽象性和理解难度。

抽象工厂

  • 定义:抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口,无须指定他们具体的类
  • 类型:创建型
  • 适用场景:客户端(应用层)不依赖与产品类实例如何被创建,实现等细节;强调一系列相关的产品对象(属于同一产品族)一起使用创建对象需要大量重复的代码;提供一个产品类的库,所有的产品以同样的接口出现,从而使客户端不依赖与具体的实现。
  • 优点:具体产品在应用层代码隔离,无须关心创建细节;将一个系列的产品族统一到一起创建。
  • 缺点:规定了所有可能被创建的产品集合,产品族中扩展新的产品困难,需要修改抽象工厂的接口;增加了系统的抽象性和理解难度。

建造者模式

  • 定义:将一根复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示;用户只需指定需要建造的类型就可以得到他们,建造过程及细节不需要知道。
  • 类型:创建型
  • 适用场景:如果一个对象有非常复杂的内部结构(很多属性);想把复杂对象的创建和使用分离
  • 优点:封装性好,创建和使用分离;扩展性好,建造类之间独立,一定程度上解耦。
  • 缺点:产生多余的Builder对象;产品内部发生变化,建造者都要修改,成本较大。

单例模式

  • 定义:保证一个类仅有一个实例,并提供一个全局访问点
  • 类型:创建型
  • 适用场景:想确保任何情况下都绝对只有一个实例
  • 优点:在内存里只有一个实例,减少了内存开销;可以避免对资源的多重占用;设置全局访问点,严格控制访问
  • 缺点:没有接口,扩展困难
  • 重点:私有构造器;线程安全;延迟加载;序列化和反序列化安全;反射

单例-Double heck

Java设计模式最全总结(完整代码+笔记)

Java设计模式最全总结(完整代码+笔记)

单例-静态内部类(基于类初始化的延迟加载解决方案)

Java设计模式最全总结(完整代码+笔记)

  • 实用技能:反编译;内存原理;多线程Debug
  • 单例相关设计模式:单例模式和工厂模式;单例模式和享元模式

原型模式

  • 定义:指原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。不需要知道任何创建的细节,不调用构造函数
  • 类型:创建型
  • 适用场景:类初始化消耗较多资源;new产生的一个对象需要非常繁琐的过程(数据准备,访问权限);构造函数比较复杂,循环体中产生大量对象时
  • 优点:原型模式性能比直接new一个对象性能高;简化创建过程
  • 缺点:必须配备克隆方法;对克隆复杂对象或对克隆出的对象进行复杂改造时,容易引人风险;深拷贝,浅拷贝要运用得当
  • 扩展:深克隆、浅克隆

结构型设计模式

外观模式

  • 定义:又叫门面模式,提供了一个统一的接口,用来访问子系统中的一群接口;外观模式定义了一个高层接口,让子系统更容易使用
  • 类型:结构型
  • 适用场景:子系统越来越复杂,增加外观模式提供简单调用接口;构建多层系统接口,利用外观对象作为每层的入口,简化层间调用
  • 优点:简化了调用过程,无需了解深入子系统,防止带来风险;减少系统依赖,松散耦合;更好的划分访问层次;符合迪米特法则,即最少知道原则
  • 缺点:增加子系统,扩展子系统行为容易引入风险;不符合开闭原则
  • 相关设计模式:外观模式和中介者模式;外观模式和单例模式;外观模式和抽象工厂模式

装饰者模式

  • 定义:在不改变原有对象的基础之上,将功能附加到对象上;提供了比继承更有弹性的替代方案(扩展原有对象的功能)
  • 类型:结构型
  • 使用场景:扩展一个类的功能或给一个类添加附加职责;动态的给一个对象添加功能,这些功能可以再动态的撤销
  • 优点:继承的有力补充,比继承灵活,不改变原有对象的情况下给一个对象扩展功能;通过使用不同装饰类以及这些装饰类的排列组合,可以实现不同效果;符合开闭原则
  • 缺点:会出现更多的代码,更多的类,增加程序复杂性;动态装饰时,多层装饰时会更复杂
  • 相关设计模式:装饰者模式和代理模式;装饰者模式和适配器模式

适配器模式

  • 定义:将一个类的接口转换成客户期望的另一个接口;使原本接口不兼容的类可以一起工作
  • 类型:结构型
  • 适用场景:已经存在的类,它的方法和需求不匹配时(方法或结果相同或相似);不是软件设计阶段考虑的设计模式,随着软件维护,由于不同产品,不同厂家造成功能类似而接口不相同情况下的解决方案
  • 优点:能提高类的透明性和复用,现有的类复用但不需要改变;目标类和适配器类解耦,提高程序扩展性;符合开闭原则
  • 缺点:适配器编写过程需要全面考虑,可能会增加系统的复杂性;增加系统代码可读的难度
  • 扩展:对象适配器、类适配器
  • 相关设计模式:适配器模式和外观模式

享元模式

  • 定义:提供了减少对象数量从而盖珊珊应用所需的对象结构的方式;运用共享技术有效地支持大量细粒度的对象
  • 类型:结构型
  • 适用场景:常常应用于系统底层的开发,以便解决系统的性能问题;系统有大量相似对象,需要缓冲池的场景。
  • 优点:减少对象的创建,降低内存中对象的数量,降低系统的内存,提高效率;减少内存之外的其他资源占用
  • 缺点:关注内/外部状态,关注线程安全问题;使系统,程序的逻辑复杂化
  • 扩展:内部状态;外部状态
  • 相关设计模式:享元模式和代理模式、享元模式和单例模式

组合模式

  • 定义:将对象组合成树形结构以表示“部分-整体”的层次结构;组合模式使客户端对单个对象和组合对象保持一致的方式处理
  • 类型:结构型
  • 适用场景:希望客户端可以忽略组合对象与单个对象的差异时;处理一个树形结构时
  • 优点:清楚地定义分层次的复杂对象,表示对象的全部或部分层次;让客户端忽略了层次的差异,方便对整个层次结构进行控制;简化客户端代码;符合开闭原则
  • 缺点:限制类型时会较为复杂;使设计变得更加抽象
  • 相关设计模式:组合模式和访问者模式

桥接模式

  • 定义:将抽象部分与它的具体实现部分分离,使它们都可以独立地变化;通过组合的方式建立两个类之间联系,而不是继承
  • 类型:结构型
  • 适用场景:抽象和具体实现之间增加更多的灵活性;一个类存在两个(或多个)独立变化的维度,且这两个(或多个)维度都需要独立进行扩展;不希望适用继承,或因为多层继承导致系统类的个数剧增
  • 优点:分离抽象部分及其具体实现部分;提高了系统的可扩展性;符合开闭原则;符合合成复用原则
  • 缺点:增加了系统的理解与设计难度;需要正确地识别出系统中两个独立变化的维度
  • 相关设计模式:桥接模式和组合模式;桥接模式和适配器模式

代理模式

  • 定义:为其他对象提供一种代理,以控制对这个对象的访问;代理对象在客户端和目标对象之间起到中介的作用
  • 类型:结构型
  • 适用场景:保护目标对象;增强目标对象
  • 优点:代理模式能将代理对象与真实被调用的目标对象分离;一定程度上降低了系统的耦合度,扩展性好;保护目标对象;增强目标对象
  • 缺点:代理模式会造成系统设计中类的数目增加;在客户端和目标对象增加一个代理对象,会造成请求处理速度变慢;增加系统的复杂度
  • 扩展:静态代理;动态代理、CGLib代理
  • spring代理选择-扩展:当Bean有实现接口时,spring就会用JDK的动态代理;当Bean没有实现接口时,Spring使用CGLib;可以强制使用CGLib(在Spring配置中加入<aop:aspectj-autoproxy proxy-target-class=“true”/>
  • 代理速度对比-扩展:CGLib、JDK动态代理、速度对比
  • 相关设计模式:代理模式和装饰者模式、代理模式和适配器模式

行为型设计模式

模板方法

  • 定义:定义了一个算法的骨架,并允许子类为一个或多个步骤提供实现;模板方法使得子类可以在不改变算法结构的情况下,重新定义算法的某些步骤
  • 类型:行为型
  • 适用场景:一次性实现一个算法的不变的部分,并将可变的行为留给子类来实现;各子类中公共的行为被提取出来并集中到一个公共父类中,从而避免代码重复
  • 优点:提高复用性;提高扩展性;符合开闭原则
  • 缺点:类数目增加;增加了系统实现的复杂度;继承关系自身缺点,如果父类添加新的抽象方法,所有子类都要改一遍
  • 扩展:钩子方法
  • 相关设计模式:模板方法模式和工厂方法模式;模板方法模式和策略模式

迭代器

  • 定义:提供一种方法,顺序访问一个集合对象中的各个元素,而又不暴露该对象的内部表示
  • 类型:行为型
  • 适用场景:访问一个集合对象的内容而无需暴露它的内部表示;为遍历不同的集合机构提供一个统一的接口
  • 优点:分离了集合对象的遍历行为
  • 缺点:类的个数成对增加
  • 相关设计模式:迭代器模式和访问者模式

策略模式

  • 定义:定义了算法家族,分别封装起来,让它们之间可以互相替换,此模式让算法的变化不会影响到使用算法的用户。
  • 类型:行为型
  • 适用场景:系统有很多类,而它们的区别仅仅在于他们的行为不同;一个系统需要动态地在几种算法中选择一种
  • 优点:开闭原则;避免使用多重条件转移语句;提高算法的保密性和安全性
  • 缺点:客户端必须知道所有的策略类,并自行决定使用哪一个策略类;产生很多策略类
  • 相关设计模式:策略模式和工厂模式;策略模式和状态模式

解释器

  • 定义:给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子;为了解释一种语言,而为语言创建的解释器
  • 类型:行为型
  • 适用场景:某个特定类型问题发生频率足够高
  • 优点:语法由很多类表示,容易改变及扩展此“语言”
  • 缺点:当语法规则数目太多时,增加了系统复杂度
  • 相关设计模式:解释器模式和适配器模式

观察者模式

  • 定义:定义了对象之间的一对多依赖,让多个观察者对象同时监听某一个主题对象,当主题对象发生变化时,它的所有依赖者(观察者)都会收到通知并更新
  • 类型:行为型
  • 适用场景:关联行为场景,建立一套触发机制
  • 优点:观察者和被观察者之间简历一个抽象的耦合;观察者模式支持广播通信
  • 缺点:观察者之间有过多的细节依赖,提高时间消耗及程序复杂度;使用要得当,要避免循环调用

备忘录模式

  • 定义:保存一个对象的某个状态,以便在适当的时候恢复对象;后悔药
  • 类型:行为型
  • 适用场景:保存及恢复数据相关业务场景;后悔的时候,即想恢复到之前的状态
  • 优点:为用户提供一种可恢复的机制,存档信息的封装
  • 缺点:资源占用
  • 相关设计模式:备忘录模式和状态模式

命令模式

  • 定义:将“请求”封装成对象,以便使用不同的请求;命令模式解决了应用程序中对象的职责以及他们之间的通信方式
  • 类型:行为型
  • 适用场景:请求调用者和请求接受者需要解耦,使得调用者和接受者不直接交互;需要抽象出等待执行的行为
  • 优点:降低耦合,容易扩展新命令或者一组命令
  • 缺点:命令的无限扩展会增加类的数量,提高系统实现复杂度
  • 相关设计模式:命令模式和备忘录模式

中介者模式

  • 定义:定义一个封装一组对象如何交互的对象;通过使对象明确地相互引用来促进松散耦合,并允许独立地改变它们的交互
  • 类型:行为型
  • 适用场景:系统中对象之间存在复杂的引用关系,产生的相互依赖关系结构混乱且难以理解;交互的公共行为,如果需要改变行为则可以增加新的中介者类
  • 优点:将一对多转化成了一对一,降低程序复杂度;类之间解耦
  • 缺点:中介者过多,导致系统复杂
  • 相关设计模式:中介者模式和观察者模式

责任链模式

  • 定义:为请求创建一个接受此次请求对象的链
  • 类型:行为型
  • 适用场景:一个请求的处理需要多个对象当中的一个或几个协作处理
  • 优点:请求的发送者和接受者(请求的处理)解耦;责任链可以动态组合
  • 缺点:责任链太长或者处理时间过长,影响性能;责任链有可能过多
  • 相关设计模式:责任链模式和状态模式

访问者模式

  • 定义:封装作用于某数据结构(如List/Set/Map等)中的各元素的操作;可以在不改变各元素的类的前提下,定义作用于这些元素的操作
  • 类型:行为型
  • 适用场景:一个数据结构(如List/Set/Map等)包含很多类型对象;数据结构与数据操作分离
  • 优点:增加新的操作很容易,即增加一个新的访问者
  • 缺点:增加新的数据结构困难;具体元素变更麻烦
  • 相关设计模式:访问者模式和迭代器模式

状态模式

  • 定义:允许一个对象在其内部状态改变时,改变它的行为
  • 类型:行为型
  • 适用场景:一个对象存在多个状态(不同状态下行为不同),且状态可相互转换
  • 优点:将不同的状态隔离;把各种状态的转换逻辑,分部到state的子类中,减少相互间依赖;增加新的状态非常简单
  • 缺点:状态多的业务场景倒置类数目增加,系统变复杂
  • 相关设计模式:状态模式和享元模式
本站所有文章均来自互联网,如有侵权,请联系站长删除。极客文库 » Java设计模式最全总结(完整代码+笔记)
分享到:
赞(0)

评论抢沙发

评论前必须登录!