设计模式笔记(7 FLYWEIGHT & PROXY)

25 篇文章 0 订阅
13 篇文章 0 订阅
FLYWEIGHT(享元)
意图:
运用共享技术有效地支持大量细粒度的对象。

适用性:
1.一个程序应用了大量的对象,造成很大的存储开销。
2.对象的大多数状态可变为外部状态。
3.如果删除对象的外部状态,那么可以用相对较少的公象对象取代很多组对象。
4.应用程序不依赖于对象标识

思考:
    上述的适用性和别的模式中介绍的不太一样。基本上,适合使用FlyWeight模式的场景需要同时满足上述四个条件,而别的模式大多只要满足适用性的一两条,就可能适合采用该模式。
    从第一个适用性条件可以看出,这基本上属于开销优化的范围。因此,除非事先有足够的领域知识能够加以预见,否则,是不必在早期设计中考虑使用该模式的。要想成功运用该模式,必须的一个条件是:除了那些外部状态,余下的状态将是需要共享的。这也就意味着一般而言,FLYWEIGHT是只读的--变化的部分仍然需要加以分离出来--从这个意义上来说,“享元”的中文翻译更好地表达了这层意思。一个最好的情况是,共享的这些对象没有外部状态,且只作为系统共享的只读对象。关于第四条,可以认为是一种补充说明,对象标识本身其实也是可以作为变化的部分加以分离的。
    上面的讨论强调了“只读”,事实上,本模式并不要求FLYWEIGHT是只读的。但是,必须看到修改FLYWEIGHT的后果:这种影响是全局的,接近于全局变量的变种。某些时候也许我们确实需要这种全局的作用效果,但是滥用这一能力可能导致理解上的困难和程序行为的判断困难。FlyWeight的主要目的不在于此。
    通常,享元也并不能当作一个纯粹的只读对象,那么,将变化的部分加以分离可能是必须的工作,也有必要对分离的效果加以评估再决定是否和如何运用FlyWeight模式。

PROXY(代理)
意图:
为其他对象提供一种代理以控制对这个对象的访问。

适用性:
书中列出了几种运用proxy的场景作为适用性的说明:
1.远程代理,为一个不在同一地址空间的对象提供局部代理。
2.虚代理,根据需要创建很大的对象。
3.保护代理控制对原始对象的访问。
4.智能引用,取代简单指针,在访问对象时提供附加操作。例如:智能指针;第一次访问持久对象时,将它装入内存;在访问一个实际对象前,检查其是否加锁。

思考:
        相对于Decorator而言,通常Proxy是更重量级的。Proxy和Bridge模式也有很多相似之处:透过一个接口去访问真正实现功能的对象。Decorator和Proxy的区别在于,Decorator目标仅仅在于增加某些方法的职责,并不打算全面掌控目标对象,另外,Decorator也并不确定自己将要修饰的可能会是什么对象。Proxy模式则相反,Proxy需要全面了解甚至需要构建被代理对象,而Proxy和被代理对象之间的关系也是静态决定的。有一点是相同的:一个实际对象既可以有多个Decorator,也可以有多个Proxy。
        Proxy和Bridge虽然有相似性,但是Bridge的目的仅仅是为了维持接口和实现的各自演化,Bridge模式并不打算用来支持创建非常复杂的实现。Bridge模式的接口和实现在语意上是完全一致的。而Proxy模式,虽然一般而言Proxy和被代理对象之间具备一致的接口,但这完全是不必要的。当弱化Proxy的额外处理能力,强化Decorator的职责范围,这三个模式之间的实现区别将会不那么显著,我们需要警惕的是,这三者之间的意图则是差别非常巨大的。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值