看作者在桥梁模式举例,iPod、MP4,哈哈,能看出书的年头了。
代码语言:javascript复制public interface Implementor {
//基本方法给别人调用
public void doSomething();
public void doAnything();
}
// 具体实现角色
public class ConcreteImplementor1 implements Implementor{
public void doSomething(){}
public void doAnything(){}
}
代码语言:javascript复制public abstract class Abstraction {
//定义对实现化角色的引用
private Implementor imp;
//约束子类必须实现该构造函数
public Abstraction(Implementor _imp){
this.imp = _imp;
}
//自身的行为和属性
public void request(){
this.imp.doSomething();
}
//获得实现化角色
public Implementor getImp(){
return imp;
}
}
public class RefinedAbstraction extends Abstraction {
public RefinedAbstraction(Implementor _imp){
super(_imp);
}
//修正父类的行为
@Override
public void request(){
/*
* 业务处理...
*/
super.request();
super.getImp().doAnything();
}
}
代码语言:javascript复制public class Client {
public static void main(String[] args) {
// 要修改,用不同的 Implementor,Abstraction 实现
// 两者在接口中已经定义好了逻辑关系
Implementor imp = new ConcreteImplementor1();
Abstraction abs = new RefinedAbstraction(imp);
abs.request();
}
}
这看代码也太简单了吧。
工作忙一些,太定制化的需求有点难搞,有时候想写漂亮一点,那就要修改架构,但别人的代码就不太愿意大改,因为一不小心就可能出问题。
有些千奇百怪的需求过来,在设计时也不太可能考虑到,或者由于工期问题,只能是遇到了再看怎么去设计扩展。
而特别加补丁,丑就丑吧,就像之前在网上看到的一个视频,一堆糖果看到一个颜色不一样的,扣掉了以为完美,结果多米诺骨牌般整个崩塌了。在程序后续的维护,不太可能完全去考虑什么原则、模式等。时间、效果的制约下,真的是能跑通不出错就行。