桥接模式

业务场景（待改造）

/**
 * 消息统一接口
 */
public interface Message {
    /**
     * 发送消息
     * @param msg
     */
    void send(String msg);
}

/**
 * 站内短消息的方式发送消息
 */
class CommonMessageSMS implements Message{
    @Override
    public void send(String msg) {
        System.out.println("使用站内短消息的方式发送消息" + msg);
    }
}

class CommonMessageEmail implements Message{
    @Override
    public void send(String msg) {
        System.out.println("使用Email的方式发送消息" + msg);
    }
}

/**
 * 加急消息的抽象接口
 */
interface UrgencyMessage extends Message{
    /**
     * 监控某消息的处理过程
     * @param messageId
     */
    void watch(String messageId);
}

class UrgencyMessageSMS implements UrgencyMessage{
    @Override
    public void send(String msg) {
        System.out.println("使用站内短消息的方式发送加急消息");
    }

    @Override
    public void watch(String messageId) {
        System.out.println("监控" + messageId);
    }
}

class UrgencyMessageEmail implements UrgencyMessage{
    @Override
    public void send(String msg) {
        System.out.println("使用Email的方式发送加急消息");
    }

    @Override
    public void watch(String messageId) {
        System.out.println("监控" + messageId);
    }
}

存在的问题：
1、后增加的UrgencyMessage必须实现Email和SMS两种方式，如果再出现一种新的消息类型，类的数量就会不合理的增长。
2、如果再增加了一种新的消息发送方式比如微信，那么所有的消息种类都要增加它的实现，很多地方都要修改。

桥接模式（改造后）

/**
 * 消息发送方式
 */
public interface SendMessageType {
    /**
     * 发送消息
     */
    void send(String message);
}

class SendBySMS implements SendMessageType{
    @Override
    public void send(String message) {
        System.out.println("站内短消息方式发送");
    }
}

class SendByEmail implements SendMessageType{
    @Override
    public void send(String message) {
        System.out.println("email方式发送");
    }
}

abstract class AbstractMessage{
    private SendMessageType sendMessageType;

    public AbstractMessage(SendMessageType sendMessageType) {
        this.sendMessageType = sendMessageType;
    }

    public void sendMessage(String message){
        sendMessageType.send(message);
    }
}

class CommonMessage extends AbstractMessage{
    public CommonMessage(SendMessageType sendMessageType) {
        super(sendMessageType);
    }
}

class UrgencyMessage extends AbstractMessage{
    public UrgencyMessage(SendMessageType sendMessageType) {
        super(sendMessageType);
    }

    void watch(String messageId){
        System.out.println("监控消息"  + messageId);
    }
}


/**
 * 新添加的发送消息种类
 */
class SendByWeChat implements SendMessageType{
    @Override
    public void send(String message) {
        System.out.println("微信方式发送");
    }
}

/**
 * 新添加的消息类型
 */
class SepialMessage extends AbstractMessage{
    public SepialMessage(SendMessageType sendMessageType) {
        super(sendMessageType);
    }

    void watch(String messageId){
        System.out.println("催促消息"  + messageId);
    }
}

定义

将抽象和具体实现分离，使它们可以独立的变化。
桥接是在被分离了的抽象部分和实现部分搭桥，维护这个关系。
桥接模式适应两个维度的变化，继承适用一个维度的变化。要求正确识别出系统中两个独立变化的维度。

UML类图

/**
 * 定义实现部分的接口
 */
public interface Implementor {
    void operationImpl();
}

/**
 * 抽象部分接口
 */
abstract class Abstraction{
    protected Implementor impl;

    public Abstraction(Implementor impl) {
        this.impl = impl;
    }

    public void operation(){
        impl.operationImpl();
    }
}

/**
 * 具体的实现类A
 */
class ConcreteImplementorA implements Implementor{
    @Override
    public void operationImpl() {

    }
}
class ConcreteImplementorB implements Implementor{
    @Override
    public void operationImpl() {

    }
}

/**
 * 扩展抽象部分的接口
 */
class RefinedAbstraction extends  Abstraction{
    public RefinedAbstraction(Implementor impl) {
        super(impl);
    }

    public void otherOperation(){

    }
}

Abstraction：抽象部分的接口。里面持有具体的Implementor抽象引用。肩负者桥接的重任。

RefinedAbstraction：扩展抽象部分接口，里面会实现实际业务方法。

Implementor：要被桥接的对象的抽象。
ConcreteImplementor：要被桥接的对象的实现。

适用场景

如果某个业务场景，有2个维度的变化，中间有交集，就适合用桥接模式解决。对比之下，如果用继承，消息类别如果有M个，发送方式有N个，共有M* N种组合，M*N个类。桥接模式能够解决这种两个变化维度的情况下的场景，继承改成了组合。