适配器模式

基本介绍:

  • 适配器模式(AdapterPattern)将某个类的接口转换成客户端期望的另一个接口表示,主的目的是兼容性,让原本因接口不匹配不能一起工作的两个类可以协同工作。其别名为包装器(Wrapper)。
  • 适配器模式属于结构型模式
  • 主要分为三类:类适配器模式、对象适配器模式、接口适配器模式

工作原理:

  • 适配器模式:将一个类的接口转换成另一种接口.让原本接口不兼容的类可以兼容
  • 从用户的角度看不到被适配者,是解耦的
  • 用户调用适配器转化出来的目标接口方法,适配器再调用被适配者的相关接口方法
  • 用户收到反馈结果,感觉只是和目标接口交互,如图

image-20200914213109728

类适配器模式

类适配器模式介绍:Adapter 类,通过继承 src 类,实现 dst 类接口,完成 src->dst 的适配。

类适配器模式应用实例

以生活中充电器的例子来讲解适配器,充电器本身相当于 Adapter,220V 交流电相当于 src (即被适配者),我们 的目 dst(即 目标)是 5V 直流电

image-20200914222241945

类适配器模式注意事项和细节

  • Java 是单继承机制,所以类适配器需要继承 src 类这一点算是一个缺点, 因为这要求 dst 必须是接口,有一定局 限性;
  • src 类的方法在 Adapter 中都会暴露出来,也增加了使用的成本。
  • 优点:由于其继承了src类,所以它可以根据需求重写src类的方法,使得Adapter的灵活性增强了。

对象适配器模式

  • 本思路和类的适配器模式相同,只是将Adapter类作修改,不是继承src类,而是持有src类的实例,以解决

    兼容性的问题。 即:持有 src 类,实现 dst 类接口,完成 src->dst 的适配

  • 根据“合成复用原则”,在系统中尽量使用关联关系(聚合)来替代继承关系。

  • 对象适配器模式是适配器模式常用的一种

应用实例说明:

以生活中充电器的例子来讲解适配器,充电器本身相当于 Adapter,220V 交流电相当于 src (即被适配者),我们 的目 dst(即目标)是 5V 直流电,使用对象适配器模式完成。

image-20200915183214205

对象适配器模式注意事项和细节:

  • 对象适配器和类适配器其实算是同一种思想,只不过实现方式不同。 根据合成复用原则,使用组合替代继承, 所以它解决了类适配器必须继承 src 的局限性问题,也不再要求 dst 必须是接口。
  • 使用成本更低,更灵活。

接口适配器模式

  • 一些书籍称为:适配器模式(DefaultAdapterPattern)或缺省适配器模式。
  • 核心思路:当不需要全部实现接口提供的方法时,可先设计一个抽象类实现接口,并为该接口中每个方法提供一个默认实现(空方法),那么该抽象类的子类可有选择地覆盖父类的某些方法来实现需求
  • 适用于一个接口不想使用其所有的方法的情况。

image-20200915190559858

适配器模式在 SpringMVC 框架应用的源码剖析

  1. SpringMvc中的HandlerAdapter,就使用了适配器模式
  2. 使用HandlerAdapter的原因分析:
    • 可以看到处理器的类型不同,有多重实现方式,那么调用方式就不是确定的,如果需要直接调用 Controller 方法,需要调用的时候就得不断是使用 if else 来进行判断是哪一种子类然后执行。那么如果后面要扩展 Controller, 就得修改原来的代码,这样违背了 OCP 原则。
  3. 代码分析+Debug源码

image-20200915215351853

image-20200915215408122

适配器模式的注意事项和细节

  1. 三种命名方式,是根据src是以怎样的形式给到Adapter(在Adapter里的形式)来命名的

  2. 类适配器:以类给到,在Adapter里,就是将src当做类,继承

    对象适配器:以对象给到,在 Adapter 里,将 src 作为一个对象,持有

    接口适配器:以接口给到,在 Adapter 里,将 src 作为一个接口,实现

  3. Adapter 模式最大的作用还是将原本不兼容的接口融合在一起工作。

  4. 实际开发中,实现起来不拘泥于我们讲解的三种经典形式

桥接模式

手机操作问题

现在对不同手机类型的不同品牌实现操作编程(比如:开机、关机、上网,打电话等),如图:

image-20200915221218357

传统方案解决手机操作问题:

image-20200915221240739

传统方案解决手机操作问题分析:

  • 扩展性问题(类爆炸),如果我们再增加手机的样式(旋转式),就需要增加各个品牌手机的类,同样如果我们增加 一个手机品牌,也要在各个手机样式类下增加。
  • 违反了单一职责原则,当我们增加手机样式时,要同时增加所有品牌的手机,这样增加了代码维护成本.
  • 解决方案-使用桥接模式

桥接模式(Bridge)-基本介绍

  • 桥接模式(Bridge模式)是指:将实现与抽象放在两个不同的类层次中,使两个层次可以独立改变。
  • Bridge 模式基于类的最小设计原则(类尽量少),通过使用封装、聚合及继承等行为让不同的类承担不同的职责。它的主要特点是把抽象(Abstraction)与行为实现(Implementation)分离开来,从而可以保持各部分的独立性以及应对他们的功能扩展
  • 是一种结构型设计模式

桥接模式(Bridge)-原理类图:

image-20200915221430000

说明:

  • Client 类:桥接模式的调用者
  • 抽象类(Abstraction) :维护了 Implementor / 即它的实现类 ConcreteImplementorA.., 二者是聚合关系, Abstraction充当桥接类
  • RefinedAbstraction : 是 Abstraction 抽象类的子类
  • Implementor : 行为实现类的接口
  • ConcreteImplementorA /B :行为的具体实现类
  • 从UML图:这里的抽象类和接口是聚合的关系,其实调用和被调用关系

桥接模式解决手机操作问题

image-20200915221624326

桥接模式在 JDBC 的源码剖析

Jdbc 的 Driver 接口,如果从桥接模式来看,Driver 就是一个接口,下面可以有 MySQL 的 Driver,Oracle 的

Driver,这些就可以当做实现接口类

image-20200915221707181

桥接模式的注意事项和细节

  1. 实现了抽象和实现部分的分离,从而极大的提供了系统的灵活性,让抽象部分和实现部分独立开来,这有助于 系统进行分层设计,从而产生更好的结构化系统。
  2. 对于系统的高层部分,只需要知道抽象部分和实现部分的接口就可以了,其它的部分由具体业务来完成。
  3. 桥接模式替代多层继承方案,可以减少子类的个数,降低系统的管理和维护成本。
  4. 桥接模式的引入增加了系统的理解和设计难度,由于聚合关联关系建立在抽象层,要求开发者针对抽象进行设计和编程
  5. 桥接模式要求正确识别出系统中两个独立变化的维度(抽象、和实现),因此其使用范围有一定的局限性,即需要有这样的应用场景。
  6. 对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统,桥接模式尤为适用.
    • JDBC驱动程序
    • 银行转账系统
      • 转账分类: 网上转账,柜台转账,AMT 转账
      • 转账用户类型:普通用户,银卡用户,金卡用户..
    • 消息管理
      • 消息类型:即时消息,延时消息
      • 消息分类:手机短信,邮件消息,QQ 消息…

装饰者设计模式

星巴克咖啡订单项目(咖啡馆)

  • 咖啡种类/单品咖啡:Espresso(意大利浓咖啡)、ShortBlack、LongBlack(美式咖啡)、Decaf(无因咖啡)
  • 调料:Milk、Soy(豆浆)、Chocolate
  • 要求在扩展新的咖啡种类时,具有良好的扩展性、改动方便、维护方便
  • 使用OO的来计算不同种类咖啡的费用:客户可以点单品咖啡,也可以单品咖啡+调料组合。

方案一

image-20200916203003942

方案 1问题分析:

  1. Drink 是一个抽象类,表示饮料
  2. des 就是对咖啡的描述, 比如咖啡的名字
  3. cost() 方法就是计算费用,Drink 类中做成一个抽象方法.
  4. Decaf 就是单品咖啡, 继承 Drink, 并实现 cost
  5. Espress && Milk 就是单品咖啡+调料, 这个组合很多
  6. 问题:这样设计,会有很多类,当我们增加一个单品咖啡,或者一个新的调料,类的数量就会倍增,就会出现类爆炸

方案二

前面分析到方案 1 因为咖啡单品+调料组合会造成类的倍增,因此可以做改进,将调料内置到 Drink 类,这样就不会造成类数量过多。从而提高项目的维护性(如图):

说明: milk,soy,chocolate 可以设计为 Boolean,表示是否要添加相应的调料

image-20200916203207006

方案 2问题分析:

  1. 方案2可以控制类的数量,不至于造成很多的类
  2. 在增加或者删除调料种类时,代码的维护量很大
  3. 考虑到用户可以添加多份调料时,可以将hasMilk返回一个对应int
  4. 考虑使用装饰者模式

装饰者模式定义

  • 装饰者模式:动态的将新功能附加到对象上。在对象功能扩展方面,它比继承更有弹性,装饰者模式也体现了 开闭原则(ocp)
  • 这里提到的动态的将新功能附加到对象和ocp原则,在后面的应用实例上会以代码的形式体现,请同学们注意 体会。

装饰者模式原理

  • 装饰者模式就像打包一个快递。主体:比如:陶瓷、衣服 (Component) // 被装饰者;包装:比如:报纸填充、塑料泡沫、纸板、木板(Decorator)
  • Component主体:比如类似前面的Drink
  • ConcreteComponent和Decorator
    • ConcreteComponent:具体的主体;比如前面的各个单品咖啡
    • Decorator:装饰者,比如各调料.

在如图的 Component 与 ConcreteComponent 之间,如果 ConcreteComponent 类很多,还可以设计一个缓冲层,将共有的部分提取出来,抽象层一个类。

image-20200916210728884

装饰者模式解决星巴克咖啡订单

image-20200916210902889

装饰者模式下的订单:2 份巧克力+一份牛奶的 LongBlack

image-20200916210924124

装饰者模式在 JDK 应用的源码分析

Java 的 IO 结构,FilterInputStream 就是一个装饰者

//说明
//1. InputStream 是抽象类, 类似我们前面讲的 Drink
//2. FileInputStream 是 InputStream 子类,类似我们前面的 DeCaf, LongBlack
//3. FilterInputStream 是 InputStream 子类:类似我们前面 的 Decorator 修饰者
//4. DataInputStream 是 FilterInputStream 子类,具体的修饰者,类似前面的 Milk, Soy 等 
//5. FilterInputStream 类 有 protected volatile InputStream in; 即含被装饰者

image-20200916215152617

组合模式

编写程序展示一个学校院系结构:需求是这样,要在一个页面中展示出学校的院系组成,一个学校有多个学院, 一个学院有多个系。如图:

image-20200916221615899

传统方案解决学校院系展示存在的问题分析:

  1. 将学院看做是学校的子类,系是学院的子类,这样实际上是站在组织大小来进行分层次的
  2. 实际上我们的要求是:在一个页面中展示出学校的院系组成,一个学校有多个学院,一个学院有多个系,因此这种方案,不能很好实现管理的操作,比如对学院、系的添加、删除和遍历等。
  3. 解决方案:把学校、院、系都看做是组织结构,他们之间没有继承的关系,而是一个树形结构,可以更好的实现管理操作。 => 组合模式

组合模式基本介绍

  • 组合模式(CompositePattern),又叫部分整体模式,它创建了对象组的树形结构,将对象组合成树状结构以 表示“整体-部分”的层次关系。
  • 组合模式依据树形结构来组合对象,用来表示部分以及整体层次。
  • 这种类型的设计模式属于结构型模式。
  • 组合模式使得用户对单个对象和组合对象的访问具有一致性,即:组合能让客户以一致的方式处理个别对象以及组合对象

image-20200916223100579

  • Component :这是组合中对象声明接口,在适当情况下,实现所有类共有的接口默认行为,用于访问和管理Component 子部件, Component 可以是抽象类或者接口
  • Leaf : 在组合中表示叶子节点,叶子节点没有子节点
  • Composite :非叶子节点, 用于存储子部件, 在 Component接口中实现 子部件的相关操作,比如增加(add)。

组合模式解决学校院系展示的应用实例

编写程序展示一个学校院系结构:需求是这样,要在一个页面中展示出学校的院系组成,一个学校有多个学院, 一个学院有多个系。

ps:实际上是把OrganizationComponent聚合到了

image-20200916223256705

组合模式在 JDK 集合的源码分析

Java 的集合类-HashMap 就使用了组合模式

  1. Map就是一个抽象的构建,类似于Component
  2. HashMap是其中一个中间的构建(Composite),实现/继承了相关方法 put/putAll
  3. Node是HashMap的静态内部类,类似于Leaf叶子结点,这里面就没有put/putAll等方法。

image-20200916223349346

组合模式的注意事项和细节

  1. 简化客户端操作。客户端只需要面对一致的对象而不用考虑整体部分或者节点叶子的问题。
  2. 具有较强的扩展性。当我们要更改组合对象时,我们只需要调整内部的层次关系,客户端不用做出任何改动.
  3. 方便创建出复杂的层次结构。客户端不用理会组合里面的组成细节,容易添加节点或者叶子从而创建出复杂的树形结构
  4. 需要遍历组织机构,或者处理的对象具有树形结构时, 非常适合使用组合模式.
  5. 要求较高的抽象性,如果节点和叶子有很多差异性的话,比如很多方法和属性都不一样,不适合使用组合模式

外观模式

影院管理项目

组建一个家庭影院: DVD 播放器、投影仪、自动屏幕、环绕立体声、爆米花机,要求完成使用家庭影院的功能,其过程为: 直接用遥控器:统筹各设备开关开爆米花机,放下屏幕,开投影仪,开音响,开 DVD,选 dvd,去拿爆米花,调暗灯光 ,播放, 观影结束后,关闭各种设备。

传统方式解决影院管理

image-20200917185013365

传统方式解决影院管理问题分析:

  • 在ClientTest的main方法中,创建各个子系统的对象,并直接去调用子系统(对象)相关方法,会造成调用过程 混乱,没有清晰的过程
  • 不利于在ClientTest中,去维护对子系统的操作
  • 解决思路:定义一个高层接口给子系统中的一组接口提供一个一致的界面(比如在高层接口提供四个方法ready, play, pause, end ),用来访问子系统中的一群接口
  • 也就是说就是通过定义一个一致的接口(界面类),用以屏蔽内部子系统的细节,使得调用端只需跟这个接口发生调用,而无需关心这个子系统的内部细节 => 外观模式

外观模式基本介绍

  • 外观模式(Facade),也叫“过程模式:外观模式为子系统中的一组接口提供一个一致的界面,此模式定义了 一个高层接口,这个接口使得这一子系统更加容易使用
  • 外观模式通过定义一个一致的接口,用以屏蔽内部子系统的细节,使得调用端只需跟这个接口发生调用,而无 需关心这个子系统的内部细节

image-20200917185143119

说明:

  • 外观类(Facade): 为调用端提供统一的调用接口, 外观类知道哪些子系统负责处理请求,从而将调用端的请求代理给适当子系统对象
  • 调用者(Client): 外观接口的调用者
  • 子系统的集合:指模块或者子系统,处理Facade对象指派的任务,他是功能的实际提供者

外观模式解决影院管理

外观模式可以理解为转换一群接口,客户只要调用一个接口,而不用调用多个接口才能达到目的。比如:在pc 上安装软件的时候经常有一键安装选项(省去选择安装目录、安装的组件等等),还有就是手机的重启功能(把 关机和启动合为一个操作)。

外观模式就是解决多个复杂接口带来的使用困难,起到简化用户操作的作用

image-20200917185322480

使用外观模式来完成家庭影院项目:

image-20200917185402101

外观模式在 MyBatis 框架应用的源码分析

MyBatis 中的 Configuration 去创建 MetaObject 对象使用到外观模式

image-20200917185434558

image-20200917185449714

外观模式的注意事项和细节

  1. 外观模式对外屏蔽了子系统的细节,因此外观模式降低了客户端对子系统使用的复杂性
  2. 外观模式对客户端与子系统的耦合关系 - 解耦,让子系统内部的模块更易维护和扩展
  3. 通过合理的使用外观模式,可以帮我们更好的划分访问的层次
  4. 当系统需要进行分层设计时,可以考虑使用Facade模式
  5. 在维护一个遗留的大型系统时,可能这个系统已经变得非常难以维护和扩展,此时可以考虑为新系统开发一个 Facade 类,来提供遗留系统的比较清晰简单的接口,让新系统与 Facade 类交互,提高复用性
  6. 不能过多的或者不合理的使用外观模式,使用外观模式好,还是直接调用模块好。要以让系统有层次,利于维 护为目的。

享元模式

展示网站项目需求

小型的外包项目,给客户 A 做一个产品展示网站,客户 A 的朋友感觉效果不错,也希望做这样的产品展示网 站,但是要求都有些不同:

  • 有客户要求以新闻的形式发布
  • 有客户人要求以博客的形式发布
  • 有客户希望以微信公众号的形式发布

传统方案解决网站展现项目:

  1. 直接复制粘贴一份,然后根据客户不同要求,进行定制修改
  2. 给每个网站租用一个空间

image-20200917220916285

存在的问题:

  • 需要的网站结构相似度很高,而且都不是高访问量网站,如果分成多个虚拟空间来处理,相当于一个相同网站 的实例对象很多,造成服务器的资源浪费
  • 解决思路:整合到一个网站中,共享其相关的代码和数据,对于硬盘、内存、CPU、数据库空间等服务器资源 都可以达成共享,减少服务器资源
  • 对于代码来说,由于是一份实例,维护和扩展都更加容易
  • 上面的解决思路就可以使用享元模式来解决

享元模式基本介绍

  • 享元模式(FlyweightPattern)也叫蝇量模式:运用共享技术有效地支持大量细粒度的对象
  • 常用于系统底层开发,解决系统的性能问题。像数据库连接池,里面都是创建好的连接对象,在这些连接对象中有我们需要的则直接拿来用,避免重新创建,如果没有我们需要的,则创建一个
  • 享元模式能够解决重复对象的内存浪费的问题,当系统中有大量相似对象,需要缓冲池时。不需总是创建新对象,可以从缓冲池里拿。这样可以降低系统内存,同时提高效率
  • 享元模式经典的应用场景就是池技术了,String常量池、数据库连接池、缓冲池等等都是享元模式的应用,享元模式是池技术的重要实现方式

image-20200917221109881

说明:

  1. FlyWeight 是抽象的享元角色, 他是产品的抽象类, 同时定义出对象的外部状态和内部状态(后面介绍) 的接口或实现
  2. ConcreteFlyWeight 是具体的享元角色,是具体的产品类,实现抽象角色定义相关业务
  3. UnSharedConcreteFlyWeight 是不可共享的角色,一般不会出现在享元工厂。
  4. FlyWeightFactory 享元工厂类,用于构建一个池容器(集合), 同时提供从池中获取对象方法

内部状态和外部状态

比如围棋、五子棋、跳棋,它们都有大量的棋子对象,围棋和五子棋只有黑白两色,跳棋颜色多一点,所以棋子颜 色就是棋子的内部状态;而各个棋子之间的差别就是位置的不同,当我们落子后,落子颜色是定的,但位置是变化 的,所以棋子坐标就是棋子的外部状态

  • 享元模式提出了两个要求:细粒度和共享对象。这里就涉及到内部状态和外部状态了,即将对象的信息分为两 个部分:内部状态和外部状态
  • 内部状态指对象共享出来的信息,存储在享元对象内部且不会随环境的改变而改变
  • 外部状态指对象得以依赖的一个标记,是随环境改变而改变的、不可共享的状态
  • 举个例子:围棋理论上有361个空位可以放棋子,每盘棋都有可能有两三百个棋子对象产生,因为内存空间有 限,一台服务器很难支持更多的玩家玩围棋游戏,如果用享元模式来处理棋子,那么棋子对象就可以减少到只有两个实例,这样就很好的解决了对象的开销问题

享元模式解决网站展现项目

image-20200917221327582

享元模式在 JDK-Interger 的应用源码分析

//如果 Integer.valueOf(x) x 在 -128 --- 127 直接,就是使用享元模式返回,如果不在 //范围类,则仍然 new
//小结:
//1. 在 valueOf 方法中,先判断值是否在 IntegerCache 中,如果不在,就创建新的 Integer(new), 否则,就 直接从 缓存池返回
//2. valueOf 方法,就使用到享元模式
//3. 如果使用 valueOf 方法得到一个 Integer 实例,范围在 -128 - 127 ,执行速度比 new 快

image-20200917221359601

享元模式的注意事项和细节

  1. 在享元模式这样理解,“享”就表示共享,“元”表示对象
  2. 系统中有大量对象,这些对象消耗大量内存,并且对象的状态大部分可以外部化时,我们就可以考虑选用享元模式
  3. 用唯一标识码判断,如果在内存中有,则返回这个唯一标识码所标识的对象,用HashMap/HashTable存储
  4. 享元模式大大减少了对象的创建,降低了程序内存的占用,提高效率
  5. 享元模式提高了系统的复杂度。需要分离出内部状态和外部状态,而外部状态具有固化特性,不应该随着内部状态的改变而改变,这是我们使用享元模式需要注意的地方.
  6. 使用享元模式时,注意划分内部状态和外部状态,并且需要有一个工厂类加以控制。
  7. 享元模式经典的应用场景是需要缓冲池的场景,比如String常量池、数据库连接池

代理模式

代理模式的基本介绍

  • 代理模式:为一个对象提供一个替身,以控制对这个对象的访问。即通过代理对象访问目标对象.这样做的好处 是:可以在目标对象实现的基础上,增强额外的功能操作,即扩展目标对象的功能。
  • 被代理的对象可以是远程对象、创建开销大的对象或需要安全控制的对象
  • 代理模式有不同的形式, 主要有三种 静态代理、动态代理 (JDK 代理、接口代理)和 Cglib 代理 (可以在内存动态的创建对象,而不需要实现接口, 他是属于动态代理的范畴) 。

image-20200918112848344

静态代理

静态代理在使用时,需要定义接口或者父类,被代理对象(即目标对象)与代理对象一起实现相同的接口或者是继 承相同父类

应用实例:

  1. 定义一个接口:ITeacherDao

  2. 目标对象TeacherDAO实现接口ITeacherDAO

  3. 使用静态代理方式,就需要在代理对象TeacherDAOProxy中也实现ITeacherDAO

  4. 调用的时候通过调用代理对象的方法来调用目标对象.

  5. 特别提醒:代理对象与目标对象要实现相同的接口,然后通过调用相同的方法来调用目标对象的方法

    image-20200918114125098

动态代理

  • 代理对象,不需要实现接口,但是目标对象要实现接口,否则不能用动态代理
  • 代理对象的生成,是利用JDK的API,动态的在内存中构建代理对象
  • 动态代理也叫做:JDK代理、接口代理
    • 代理类所在包:java.lang.reflect.Proxy
    • JDK 实现代理只需要使用 newProxyInstance 方法,但是该方法需要接收三个参数,完整的写法是: static Object newProxyInstance(ClassLoader loader, Class<?>[] interfaces,InvocationHandler h )
      • ClassLoader loader : 指定当前目标对象使用的类加载器, 获取加载器的方法固定
      • Class<?>[] interfaces: 目标对象实现的接口类型,使用泛型方法确认类型
      • InvocationHandler h : 事情处理,执行目标对象的方法时,会触发事情处理器方法, 会把当前执行的目标对象方法作为参数传入。需要重写其中的invoke()方法。

image-20200918114304464

Cglib 代理

  • 静态代理和JDK代理模式都要求目标对象是实现一个接口,但是有时候目标对象只是一个单独的对象,并没有实 现任何的接口,这个时候可使用目标对象子类来实现代理-这就是 Cglib 代理
  • Cglib 代理也叫作子类代理,它是在内存中构建一个子类对象从而实现对目标对象功能扩展, 有些书也将 Cglib 代 理归属到动态代理。
  • Cglib 是一个强大的高性能的代码生成包,它可以在运行期扩展 java 类与实现 java 接口.它广泛的被许多 AOP 的 框架使用,例如 Spring AOP,实现方法拦截
  • 在AOP编程中如何选择代理模式:
    • 目标对象需要实现接口,用 JDK 代理
    • 目标对象不需要实现接口,用 Cglib 代理
  • Cglib 包的底层是通过使用字节码处理框架 ASM 来转换字节码并生成新的类

Cglib 代理模式实现步骤:

  1. 需要引入cglib的jar文件
  2. 在内存中动态构建子类,注意代理的类不能为final,否则报错 java.lang.IllegalArgumentException
  3. 目标对象的方法如果为final/static,那么就不会被拦截,即不会执行目标对象额外的业务方法.

image-20200918114549023

几种常见的代理模式介绍(几种变体)

防火墙代理: 内网通过代理穿透防火墙,实现对公网的访问。

缓存代理:当请求图片文件等资源时,先到缓存代理取,如果取到资源则 ok,如果取不到资源,再到公网或者数据 库取,然后缓存。

远程代理:远程对象的本地代表,通过它可以把远程对象当本地对象来调用。远程代理通过网络和真正的远程对象沟通信息

同步代理:主要使用在多线程编程中,完成多线程间同步工作