2022-10-11-桥梁模式

看作者在桥梁模式举例，iPod、MP4，哈哈，能看出书的年头了。

public interface Implementor { 
    //基本方法给别人调用
    public void doSomething(); 
    public void doAnything();
}
// 具体实现角色
public class ConcreteImplementor1 implements Implementor{ 
    public void doSomething(){} 
    public void doAnything(){} 
}

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();
    }
}

public class Client {  
    public static void main(String[] args) {
        // 要修改，用不同的 Implementor，Abstraction 实现
        // 两者在接口中已经定义好了逻辑关系
        Implementor imp = new ConcreteImplementor1();
        Abstraction abs = new RefinedAbstraction(imp);  
        abs.request();
    } 
}

这看代码也太简单了吧。

工作忙一些，太定制化的需求有点难搞，有时候想写漂亮一点，那就要修改架构，但别人的代码就不太愿意大改，因为一不小心就可能出问题。

有些千奇百怪的需求过来，在设计时也不太可能考虑到，或者由于工期问题，只能是遇到了再看怎么去设计扩展。

而特别加补丁，丑就丑吧，就像之前在网上看到的一个视频，一堆糖果看到一个颜色不一样的，扣掉了以为完美，结果多米诺骨牌般整个崩塌了。在程序后续的维护，不太可能完全去考虑什么原则、模式等。时间、效果的制约下，真的是能跑通不出错就行。