设计模式-代理模式和装饰者模式

二者都是结构型的设计模式.

1.代理模式

1.1定义

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

代理从code实现方面分为静态代理和动态代理两种；

从适用范围来看,分为远程代理,虚拟代理,保护代理,智能引用几种.

远程代理:为某个对象在不同的内存地址空间提供局部代理,使得系统可以使得server部分的实现隐藏,以便client可以不必考虑Server存在.

虚拟代理,使用一个虚拟对象代理一个十分消耗资源的对象并在真正需要时才创建.

保护代理:使用代理控制对原始对象的访问,常用于被代理对象具有不同访问权限的情况.
智能引用:在访问原始对象时,执行一些自己的附加操作并对指向原始对象的引用计数.

1.2适用场景

当无法或者不想直接访问某个对象或者访问某个对象存在困难时可以通过一个代理对象来间接访问,为了保证客户端使用的透明性, 委托对象与代理对象需要实现相同的接口.

1.3代理模式的UML类图

1.4Android中的代理

Android中使用的Context,实际实现为ContextImpl；就startService() API而言, Activity间接继承自Context, 代理了ContextImpl.

2.装饰者模式

2.1定义

动态地给某个对象额外增加一些职责, 相对子类来说,装饰者更加灵活.

2.2适用场景

需要透明且动态的扩展类功能.

2.3装饰者模式UML类图

2.4 Android中的装饰者模式

同样地, 从上述Context和ContextImpl类关系图来看, 就针对startActivity API而言, Activity相当于Decorator的角色扩充了其功能, 如果单纯从ContextImpl的实现而言,其起码要求非从Activity启动另外一个Activity时,需要是NEW_TASK栈的形式,否则将抛出异常,程序不被允许这么干.

而Activity中本身覆写的方法中却没了这个限制,从某方面来说,扩充了这个API的能力.

3.异同点

从上述两个UML图看,Decorator类似于ProxySubject, 都是持有ConcreteXXX实例对象, 看着非常相似.

代理模式: 主要强调访问控制范围.

装饰者模式:主要强调增强附加功能.

这二者看起来既似代理,又似装饰者, 傻傻分不清楚.