1700476016
1700476017
this.imp.doSomething（）；
1700476018
1700476019
}
1700476020
1700476021
//获得实现化角色
1700476022
1700476023
public Implementor getImp（）{
1700476024
1700476025
return imp；
1700476026
1700476027
}
1700476028
1700476029
}
1700476030
1700476031
各位可能要问，为什么要增加一个构造函数？答案是为了提醒子类，你必须做这项工作，指定实现者，特别是已经明确了实现者，则尽量清晰明确地定义出来。我们来看具体的抽象化角色，如代码清单29-19所示。
1700476032
1700476033
代码清单29-19 具体抽象化角色
1700476034
1700476035
public class RefinedAbstraction extends Abstraction{
1700476036
1700476037
//覆写构造函数
1700476038
1700476039
public RefinedAbstraction（Implementor_imp）{
1700476040
1700476041
super（_imp）；
1700476042
1700476043
}
1700476044
1700476045
//修正父类的行为
1700476046
1700476047
@Override
1700476048
1700476049
public void request（）{
1700476050
1700476051
/*
1700476052
1700476053
*业务处理……
1700476054
1700476055
*/
1700476056
1700476057
super.request（）；
1700476058
1700476059
super.getImp（）.doAnything（）；
1700476060
1700476061
}
1700476062
1700476063
}
1700476064
1700476065
想想看，如果我们的实现化角色有很多的子接口，然后是一堆的子实现。如果在构造函数中不传递一个尽量明确的实现者，代码就很不清晰。我们来看场景类如何模拟，如代码清单29-20所示。
[
上一页 ]
[ :1.700476016e+09 ]
[
下一页 ]