设计模式学习笔记(十六)—Proxy模式

一、Proxy模式定义:

为其他对象提供一种代理以控制这个对象的访问。

二、模式解说

Proxy代理模式是一种结构型设计模式,主要解决的问题是:在直接访问对象时带来的问题,比如说:要访问的对象在远程的机器上。在面向对象系统中,有些对象由于某些原因(比如对象创建开销很大,或者某些操作需要安全控制,或者需要进程外的访问),直接访问会给使用者或者系统结构带来很多麻烦,我们可以在访问此对象时加上一个对此对象的访问层,这个访问层也叫代理。Proxy模式是最常见的模式,在我们生活中处处可见,例如我们买火车票不一定非要到火车站去买,可以到一些火车票的代售点去买。寄信不一定是自己去寄,可以把信委托给邮局,由邮局把信送到目的地,现实生活中还有很多这样的例子,就不一一列举了。

三、结构图

Proxy模式结构图如下:

四、一个例子

举一个比较俗的例子,一个男孩boy喜欢上了一个女孩girl,男孩一直想认识女孩,直接去和女孩打招呼吧,又觉得不好意思(这个男孩比较害羞)。于是男孩想出了一个办法,委托女孩的室友Proxy去帮他搞定这件事(获得一些关于女孩的信息,如有没有BF等,这就叫知己知彼,才能百战不殆)。下面给出这个例子的程序实现:

interface GirlInfo{
public void hasBoyFriend();
}
class Girl implements GirlInfo{

public void hasBoyFriend(){
 System.out.println("还没有男朋友");

}
}
class Proxy implements GirlInfo{
  private GirlInfo _girl;
  public Proxy(GirlInfo girl){
  _girl=girl;
  }
public void hasBoyFriend(){
 _girl.hasBoyFriend();

}
}
public class ProxyClient {

public static void main(String[] args) {
  GirlInfo girl=new Girl();
     Proxy proxy=new Proxy(girl);
     proxy.hasBoyFriend();
}

}

时间: 2024-12-31 01:41:12

设计模式学习笔记(十六)—Proxy模式的相关文章

设计模式学习笔记(十)—Factory Method模式

<设计模式>一书对Factory Method模式是这样描述的: 定义一个用于创建对象的接口,让子类决定实例化哪一个类.FactoryMethod使一个类的实例化延迟到其子类. 我的理解:FatoryMethod模式是一种创建型模式,定义一个用于创建对象的接口的意思是说,我们要定义一个用于创建对象的接口(或者说抽象类,实际上就是个抽象工厂abstractFactory),它的内部有一个创建对象的方法,这个方法的返回值是一个接口(或者抽象类)的类型,这个方法就是FactoryMethod:让子类

设计模式学习笔记(十五)—State模式

一.State模式定义: 允许一个对象在其状态改变时,改变它的行为.看起来对象似乎修改了它的类. 二.模式解说 State模式主要解决的是在开发中时常遇到的根据不同的状态需要进行不同的处理操作的问题,而这样的问题,大部分人是采用switch-case语句进行处理的,这样会造成一个问题:分支过多,而且如果加入一个新的状态就需要对原来的代码进行编译.State模式采用了对这些不同的状态进行封装的方式处理这类问题,当状态改变的时候进行处理然后再切换到另一种状态,也就是说把状态的切换责任交给了具体的状态

设计模式学习笔记(十四)—Command模式

一.Command模式定义: 将一个请求封装为一个对象,从而使你不同的请求对客户进行参数化:对请求排队或记录请求日志,以及支持可撤销的操作. 二.模式解说 Commad模式是一种对象行为模式,它可以对发送者(sender)和接收者(receiver)完全解耦(decoupling).("发送者" 是请求操作的对象,"接收者" 是接收请求并执行某操作的对象.有了 "解耦",发送者对接收者的接口一无所知.)这里,"请求"(requ

kvm虚拟化学习笔记(十六)之kvm虚拟化存储池配置

原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 .作者信息和本声明.否则将追究法律责任.http://koumm.blog.51cto.com/703525/1304196 KVM虚拟化学习笔记系列文章列表 ---------------------------------------- kvm虚拟化学习笔记(一)之kvm虚拟化环境安装http://koumm.blog.51cto.com/703525/1288795 kvm虚拟化学习笔记(二)之linuxkvm虚拟机安装htt

设计模式学习笔记(三)—-Strategy策略模式

GOF<设计模式>一书对Strategy模式是这样描述的: 定义一系列的算法,把他们一个个封装起来,并且使它们可相互替换.Strategy模式使算法可独立于使用它的客户而变化. Strategy模式以下列几条原则为基础: 1)每个对象都是一个具有职责的个体. 2)这些职责不同的具体实现是通过多态的使用来完成的. 3)概念上相同的算法具有多个不同的实现,需要进行管理. 下面我将通过一个实例来说明它的具体使用,这个例子是关于数据库连接的.代码如下: interface DatabaseStrate

设计模式学习笔记(一) Facade外观模式

GOF<设计模式>一书对Facade模式是这样描述的: 为子系统中的一组接口提供一个统一接口.Facade模式定义了一个更高层的接口,使子系统更加容易使用. 大致意思是说:使用一种比原有方式更简单的办法与系统交互.例如,我们把一个很文件的文件,放在了第二抽屉里,而第二个抽屉的钥匙放在了第一个抽屉里,我们要想取出这个文件,第一步肯定要拿到第一个抽屉的钥匙,然后打开它再拿出第二个抽屉的钥匙,最后打开第二个抽屉取出文件. 我就上面说的那个情形写一下实现代码,首先我们要实现二个子系统,呵呵,把抽屉比喻

设计模式学习笔记(十九)—Chain of Responsibility职责链模式

由于本人水平有限,写出来的东西也许对初学者有所帮助.如果不小心哪位大侠看了不要见笑,哪里有不正确的地方还请批评指正.好了不说废话了. Chain of Responsibility模式定义: 为了避免请求的发送者和接收者之间的耦合关系,使多个接受对象都有机会处理请求.将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止. 我的理解: 在不止一个对象可以处理客户端请求的时候,为了使每个对象都有处理请求的机会,把这些对象顺序地串联起来形成一个链,每个被串联的对象都有一个指向下一个对

设计模式学习笔记(十八)—Mediator中介者模式

一.模式定义: 用一个中介者对象来封装一系列的对象交互.中介者使各对象不需要显式的相互引用,从而使其耦合松散,而且可以独立的改变他们之间的交互. 二.结构图 1) 抽象中介者:定义同事(Colleague)对象到中介者(Mediatior)对象的接口,通常是一个事件方法. 2) 具体中介者:具体中介者实现抽象中介者声明的方法.知晓所有的具体同事类,从具体同事接收消息向另外的具体同事类发送命令. 3) 抽象同事类:定义中介者到同事对象的接口,同事对象只知道中介者而不知道其他同事对象. 三.一个例子

设计模式学习笔记(十二)—Builder建造者模式

Builder模式定义: 将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示. 刚接触到这个模式的时候,实在搞不明白它的意思,有什么用.于是,上网google了一圈,终于得到这个大家普遍认可的解释: 建造模式是一步一步创建一个复杂的对象,它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们,用户不知道内部的具体构建细节. 下面举一个例子来说明这个模式的使用,代码如下: import java.util.ArrayList; interface Builder{ pub