温习下装饰者模式(定义)
从命名可以看出,装饰,在原来的物质之上覆盖一些个性化需求,仅仅是覆盖,不改变其本来的实质;
应了那句谚语“美味的早餐,但很难识别其真实的面目”,道道都很浅显易懂,但执行起来却很容易忽视
举个常用的例子,不同系统接口经常需要不同的报文通讯,那我们来看下:
//请求接口
public interface IRequest extends Serializable {
Object assemble();//组装报文
}
为什么写接口呢,不明白的同学可以看看java基础设计规范,“依赖倒置原则”:〔要依赖抽象,不要依赖具体类〕
//请求基类
public class BaseRequest implements IRequest {
private static final long serialVersionUID = 1L;
private IRequest request;
public BaseRequest(IRequest request) {
super();//关注点,实现父类构造器
this.request = request;
}
public Object assemble() {
return this.request.assemble();//组装接口
}
}
有个接口、有个基类,既然是装饰,那大家是有共性的,否则怎么动态添加想要的功能或职责呢,我们继续:
//公共信息
public class PublicRequest extends BaseRequest {
private static final long serialVersionUID = 1L;
public PublicRequest(IRequest request) {
super(request);
}
/** 服务名 */
protected String serviceName;
public String getServiceName() {
return serviceName;
}
public void setServiceName(String serviceName) {
this.serviceName = serviceName;
}
public Object assemble() {
String request=(String) super.assemble();//关注点,执行父类组装
//拼接基础报文......
return request;
}
}
如下是个性信息类:
public class RequestOf* extends BaseRequest {//个性信息类
private static final long serialVersionUID = 1L;
public PayRequestOf*(IRequest request) {
super(request);
}
/** 姓名 */
protected String name;
public String getName() {
return name;
}
public void setCustomerName(String name) {
this.name= name;
}
public Object assemble() {
String request=(String) super.assemble();
//拼接个性报文...
return request;
}
}
我们在凭借各种不同的报文时候
IRequest channel1Request=new RequestOf*(new PublicRequest());
//是不是很方便呢
IRequest channel1Request=new RequestOf*(new RequstOf*(new PublicRequest())).......
软件来源于生活,应用于生活