Java设计模式02

设计模式分类(23种)

  • 创建型模式
    • 工厂模式、抽象工厂模式、单例模式、建造者模式、原型模式
  • 结构型模式
    • 适配器模式、代理模式装饰者模式、外观模式、桥接模式、组合模式、享元模式
  • 行为型模式
    • 观察者模式、策略模式、模板方法模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式
  • 其他
    • 并发型模式和线程池模式

抽象工厂模式

  • 应用场景
    • 用于创建相关或依赖对象的家族,而无需明确指定具体类。
  • 概念
    • 当一个产品族中需要被设计在一起工作时,通过抽象工厂模式,能够保证客户端始终只使用同一个产品族中的对象;并且通过隔离具体类的生成,使得客户端不需要明确指定具体生成类;所有的具体工厂都实现了抽象工厂中定义的公共接口,因此只需要改变具体工厂的实例,就可以在某种程度上改变整个软件系统的行为。
    • 但该模式的缺点在于添加新的行为时比较麻烦,如果需要添加一个新产品族对象时,需要更改接口及其下所有子类,这必然会带来很大的麻烦。
    • 抽象工厂 AbstractFactory:定义了一个接口,这个接口包含了一组方法用来生产产品,所有的具体工厂都必须实现此接口。
    • 具体工厂 ConcreteFactory:用于生产不同产品族,要创建一个产品,用户只需使用其中一个工厂进行获取,完全不需要实例化任何产品对象。

外观模式

  • 应用场景
    • 访问的子系统拥有复杂额结构,内部调用繁杂,初接触者根本无从下手时
  • 概念
    • 提供了一个统一的接口,用来访问子系统中的一群接口,从而让子系统更容易使用。外观定义了一个高层接口,让子类系统更容易使用

桥接模式

  • 应用场景
    • 如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性,避免在两个层次之间建立静态的继承联系,通过桥接模式可以使它们在抽象层建立一个关联关系
    • 对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统,桥接模式尤为适用
    • 一个类存在两个独立变化的维度,且这两个维度都需要进行扩展
  • 概念
    • 把抽象化与实现化解耦,使得二者可以独立变化

组合模式

  • 应用场景
    • 出现树形结构。例如文件目录显示,多及目录呈现等树形结构数据的操作
  • 概念
    • 将对象组合成树形结构来表示“整体/部分”层次关系,允许用户以相同的方式处理单独对象和组合对象
    • 组件(Component)类是组合类(Composite)和叶子类(Leaf)的父类,可以把组合类看成是树的中间节点
    • 组合对象拥有一个或者多个组件对象,因此组合对象的操作可以委托给组件对象去处理,而组件对象可以是另一个组合对象或者叶子对象

享元模式

  • 应用场景
    • 如果一个应用程序使用了大量的对象,而大量的这些对象造成了很大的存储开销时就应该考虑使用;还有就是对象的大多数状态可以外部状态,如果删除对象的外部状态,那么可以用相对较少的共享对象取代很多组对象,此时可以考虑使用享元模式
  • 概念
    • 享元模式要求能够被共享的对象必须是细粒度对象,它又称为轻量级模式,享元模式是一种对象结构型模式
    • 特点:避免重复创建对象,节省内存空间。根据内部状态把对象存储在共享池,需要时去共享池取就行

策略模式

  • 应用场景
    • 当系统能在几种算法中快速地切换,或系统中有一些类,它们仅行为不同时,或系统中存在多重条件选择语句时
  • 概念
    • 定义一系列的算法,将算法进行封装、隔离、相互独立、并且使他们相互转换
    • 抽象策略角色(Strategy)接口定义了一个算法族,它们都实现了behavior()方法
    • 具体策略(ConcreteStrategy)角色,实现抽象策略中的具体操作,该类含有具体的算法
    • 封装角色(Context)是使用到该算法族的类,其中的doSomething()方法会调用behavior(),setStrategy(Strategy)方法可以动态地改变strategy对象,也就是说能动态地改变Context所使用的算法

模板方法模式

  • 应用场景
    • 模板模式就是通过抽象类来定义一个逻辑模板,逻辑框架、逻辑原型,然后将无法决定的部分抽象成抽象类交由子类来实现,一般这些抽象类的调用逻辑还是在抽象类中完成的
  • 概念
    • 定义算法框架,并将一些步骤的实现延迟到子类。通过模板方法,子类可以重新定义算法的某些步骤,而不用改变算法的结构

迭代器模式

  • 应用场景
    • 访问一个聚合对象的内容而无需暴露它的内部表示
    • 支持对聚合对象的多种遍历
    • 为遍历不同的聚合结构提供一个统一的接口
  • 概念
    • 提供一种顺序访问聚合对象元素的方法,并且不暴露聚合对象的内部表示。这个模式给使用者提供了一种方法,可以顺序访问一个聚集对象中的元素,而又不用知道内部是如何表示的

责任链模式

  • 应用场景
    • 多个对象可以处理同一个请求,但具体由哪个对象处理则在运行时动态决定
    • 在请求处理者不明确的情况下向多个对象中的一个提交一个请求
    • 需要动态指定一组对象处理请求
  • 概念
    • 通过一条链来处理某个请求,当请求满足某个节点的条件时就在这里被处理,否则的话就会继续向下执行
    • 使多个对象都有机会处理请求,从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有对象处理它为止

命令模式

  • 应用场景
    • 向某些对象发送请求,但是并不知道请求的接受者是谁,也不知道请求的操作是什么,将‘对象的请求者‘从’命令的执行者’中解耦
  • 概念
    • 将“请求”封装成对象,以便使用不同的请求队列或者日志来参数化其他对象
    • Command:命令接口对象
    • Receiver:命令接收者,也就是命令真正的执行者
    • Invoker:通过它来调用命令
    • Client:可以设置命令与命令的接收者

备忘录模式

  • 应用场景
    • 浏览器回退,数据库备份与还原,编辑器撤销与重做,虚拟机生成快照与恢复,Git版本管理,棋牌游戏悔棋
  • 概念
    • 在不违反封装的情况下获得对象的内部状态,从而在需要时可以将对象恢复到最初状态

状态模式

  • 应用场景
    • 软件开发过程中,应用程序可能会根据不同的情况作出不同的处理。最直接的解决方案是将这些所有可能发生的情况全都考虑到,然后用if… ellse语句来做状态判断来进行不同情况的处理。但是对复杂状态的判断很吃力。随着增加新的状态或者修改一个状体(if else(或switch case)语句的增多或者修改)可能会引起很大的修改,而程序的可读性,扩展性也会变得很弱,维护麻烦
  • 概念
    • 允许对象在内部状态改变时改变它的行为,对象看起来好像修改了它所属的类
    • 将状态封装成了独立的类,并且将动作委托到代表当前状态的对象上,我们知道行为会随着内部状态的改变而改变

访问者模式

  • 应用场景
    • 系统中的某些对象,它们存储在同一个集合中,且具有不同的类型,而且对于该集合中的对象,可以接受一类称为访问者的对象来访问,而且不同的访问者其访问方式有所不同
    • 对同一集合对象的操作并不是唯一的,对相同的元素对象可能存在多种不同的操作方式。而且这些操作方式并不稳定,可能还需要增加新的操作,以满足新的业务需求
    • 目的是封装一些施加于某种数据结构元素之上的操作,一旦这些操作需要修改的话,接受这个操作的数据结构可以保持不变
    • 为不同类型的元素提供多种访问操作方式,且可以在不修改原有系统的情况下增加新的操作方式,这就是访问者模式的模式动机
  • 概念
    • 表示一个作用于某对象结构中的各元素的操作,它使我们可以在不改变各元素的类的前提下定义作用于这些元素的新操作

中介者模式

  • 应用场景
    • 系统中对象之间存在比较复杂的引用关系,导致他们之间的依赖关系结构混乱而且难以复用该对象,可以引入中介这模式,将多个逻辑关联的对象之间进行解耦
    • DataX是阿里巴巴集团内被广泛使用的离线数据同步工具/平台,实现包括MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS等各种异构数据源之间高效的数据同步功能。DataX其实相当于一个中介,从数据源读取数据,写入到目标端,数据源不再需要维护到目标端的同步作业,只需要与DataX通信即可。DataX体现了中介者模式的思想
  • 概念
    • 用一个中介对象(中介者)来封装一系列的对象交互,中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互

解释器模式

  • 应用场景
    • 给定一个语言后,解释器模式可以定义出其文法的一种表示,并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子
    • 可以将一个需要解释执行的语言中的句子表示为一个抽象语法树
    • 一些重复出现的问题可以用一种简单的语言来进行表达
    • 一个简单语法需要解释的场景
  • 概念
    • 为语言创建解释器,通常由语言的语法和语法分析来定义

MVC设计模式

  • MVC是Model-View-Controller的简称,即模型-视图-控制器
  • MVC是一种设计模式,它把应用程序分成三个核心模块,模型、视图、控制器
  • 其实MVC不是设计模式,是一个比设计模式更大一点的模式,称作设计模式不合理,应该说MVC它是一种软件开发架构模式,它包含了很多的设计模式,最为密切是以下三种:Observer(观察者模式), Composite(组合模式)和Strategy(策略模式)。所以说MVC模式又称复合模式。MVC模式的基本思想是数据,显示和处理相分离。模型(Model)负责数据管理,视图(View)负责数据显示,控制器(Controller)负责业务逻辑和响应策略
  • 模型(Model)是应用程序的主体部分,表示业务数据和业务逻辑,一个模型能为多个View提供数据,由于同一个模型可以被多个视图重用,所以提高了应用的可重用性
  • 视图(View)是用户看到并与之交互的界面,视图向用户显示相关的数据,并能接收用户的输入数据,但是它不进行任何的业务处理
  • 控制器(Controller)接收用户的输入并调用模型和视图去完成用户请求,当Web用户单击页面中的提交按钮来发送html表单时,控制器接收请求并调用相应模型组件去处理请求,然后调用相应的视图来显示模型返回的数据
  • 结构:View<=>Controller<=>Model<=>sql //任何进入视图的路径必须要通过控制器
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值