装饰者模式
装饰者模式是非常常见的设计模式之一,写个笔记,记录一下我的学习过程和心得。
首先了解一些装饰模者式的定义。
动态地给一个对象添加一些额外的职责。就增加功能来说,装饰模式相比生成子类更为灵活。
- 装饰者模式属于结构型模式。
- 装饰者模式在生活中应用实际上也非常广泛,一如一间房,放上厨具,它就是厨房;放上床,就是卧室。
- 通常我们扩展类的功能是通过继承的方式来实现,但是装饰者模式是通过组合的方式来实现,这是继承的替代方案之一。
涉及角色及说明:
Component(抽象组件):接口或者抽象类,被装饰的最原始的对象。具体组件与抽象装饰角色的父类。
ConcreteComponent(具体组件):实现抽象组件的接口。
Decorator(抽象装饰角色):一般是抽象类,抽象组件的子类,同时持有一个被装饰者的引用,用来调用被装饰者的方法;同时可以给被装饰者增加新的职责。
ConcreteDecorator(具体装饰类):抽象装饰角色的具体实现。
就以装修房间为例子,讲一下实现。
1 创建抽象组件
这里是一个抽象房子类,定义一个装修的方法:
public abstract class Room {
public abstract void fitment();//装修方法
}
2 创建具体组件
现在有一间新房子,已经装上了电:
public class NewRoom extends Room {//继承Room
@Override
public void fitment() {
System.out.println("这是一间新房:装上电");
}
}
3 创建抽象装饰角色
要为房子装修,定义抽象的房间装饰类:
public abstract class RoomDecorator extends Room {//继承Room,拥有父类相同的方法
private Room mRoom;//持有被装饰者的引用,这里是需要装修的房间
public RoomDecorator(Room room) {
this.mRoom = room;
}
@Override
public void fitment() {
mRoom.fitment();//调用被装饰者的方法
}
}
4 创建具体装饰类
我们要将房间装修成卧室和厨房,其具体实现是不同的:
public class Bedroom extends RoomDecorator {//卧室类,继承自RoomDecorator
public Bedroom(Room room) {
super(room);
}
@Override
public void fitment() {
super.fitment();
addBedding();
}
private void addBedding() {
System.out.println("装修成卧室:添加卧具");
}
}
public class Kitchen extends RoomDecorator {//厨房类,继承自RoomDecorator
public Kitchen(Room room) {
super(room);
}
@Override
public void fitment() {
super.fitment();
addKitchenware();
}
private void addKitchenware() {
System.out.println("装修成厨房:添加厨具");
}
}
5 客户端测试:
public void test() {
Room newRoom = new NewRoom();//有一间新房间
RoomDecorator bedroom = new Bedroom(newRoom);
bedroom.fitment();//装修成卧室
RoomDecorator kitchen = new Kitchen(newRoom);
kitchen.fitment();//装修成厨房
}
输出结果:
这是一间新房:装上电
装修成卧室:添加卧具
这是一间新房:装上电
装修成厨房:添加厨具
广泛应用
我们都知道Activity
、Service
、Application
等都是一个Context
,这里面实际上就是通过装饰者模式来实现的。下面以startActivity()
这个方法来简单分析一下。
1 Context类
Context
实际上是个抽象类,里面定义了大量的抽象方法,其中就包含了startActivity()
方法:
public abstract class Context {//抽象类
public abstract void startActivity(@RequiresPermission Intent intent);//抽象方法
//其他代码略
}
2 ContextImpl类
Context
类的具体实现实际上是在ContextImpl
类,里面具体实现了startActivity()
方法:
class ContextImpl extends Context {
@Override
public void startActivity(Intent intent) {
warnIfCallingFromSystemProcess();
startActivity(intent, null);
}
@Override
public void startActivity(Intent intent, Bundle options) {//具体实现原理这里就不分析了
warnIfCallingFromSystemProcess();
// Calling start activity from outside an activity without FLAG_ACTIVITY_NEW_TASK is
// generally not allowed, except if the caller specifies the task id the activity should
// be launched in.
if ((intent.getFlags() & Intent.FLAG_ACTIVITY_NEW_TASK) == 0
&& options != null && ActivityOptions.fromBundle(options).getLaunchTaskId() == -1) {
throw new AndroidRuntimeException(
"Calling startActivity() from outside of an Activity "
+ " context requires the FLAG_ACTIVITY_NEW_TASK flag."
+ " Is this really what you want?");
}
mMainThread.getInstrumentation().execStartActivity(
getOuterContext(), mMainThread.getApplicationThread(), null,
(Activity) null, intent, -1, options);
}
//其他代码略
}
3 ContextWrapper类
通常我们在Activity
、Service
里面调用startActivity()
方法,实际上是调用他们的父类ContextWrapper
里面的startActivity()
方法,我们先来看下Activity
、Service
的继承关系:
可以看到Activity
、Service
都是继承自ContextWrapper
,再来看看ContextWrapper
的代码:
public class ContextWrapper extends Context {//Context包装类
Context mBase;//持有Context引用
public ContextWrapper(Context base) {//这里的base实际上就是ContextImpl
mBase = base;
}
@Override
public void startActivity(Intent intent) {
mBase.startActivity(intent);//调用ContextImpl的startActivity()方法
}
//其他代码略
}
4 总结
Context
类在这里就充当了抽象组件的角色,ContextImpl
类则是具体的组件,而ContextWrapper
就是具体的装饰角色,通过扩展ContextWrapper
增加不同的功能,就形成了Activity
、Service
等子类。最后,放一张总的UML类图帮助理解:
总结
装饰模式 VS 继承
- 装饰模式:对于一个给定的对象,同时可能有不同的装饰对象,客户端可以通过它的需要选择合适的装饰对象发送消息。
- 继承:对于所有可能的联合,客户期望很容易增加任何的 困难
装饰模式 | 继承 |
---|---|
用来扩展特定对象的功能 | 用来扩展一类对象的功能 |
不需要子类 | 需要子类 |
动态地 | 静态地 |
运行时分配职责 | 编译时分派职责 |
防止由于子类而导致的复杂和混乱 | 导致很多子类产生,在一些场合,报漏类的层次 |
更多的灵活性 | 缺乏灵活性 |
总结一下装饰者模式的优缺点
优点
采用组合的方式,可以动态的扩展功能,同时也可以在运行时选择不同的装饰器,来实现不同的功能。
有效避免了使用继承的方式扩展对象功能而带来的灵活性差,子类无限制扩张的问题。
被装饰者与装饰者解偶,被装饰者可以不知道装饰者的存在,同时新增功能时原有代码也无需改变,符合开放封闭原则。
缺点
装饰层过多的话,维护起来比较困难。
如果要修改抽象组件这个基类的话,后面的一些子类可能也需跟着修改,较容易出错。
适用场景
需要扩展一个类的功能,或给一个类增加附加功能时
需要动态的给一个对象增加功能,这些功能可以再动态的撤销
当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时。
网友评论