桥梁模式Bridge

• 桥梁模式是将抽象化和实例化脱耦，使两者可以独立变化
• 我的理解，如果对于一个抽象接口，我们直接用具体的业务逻辑实现之，那么两者是密不可分的。一旦抽象接口发生变化，那么我们实现的具体业务逻辑也必须修改。对于系统设计而言，开始设立的抽象接口，是所有实现的本源，可以有多套实现。而一旦发现系统需要扩展，抽象接口需要改动，从而导致所有实现该接口的业务逻辑也需要对应修改。这与开放封闭原则背道而驰。此时，桥梁模式可以把抽象接口修改的影响控制在接口区。桥梁模式也被叫做接口模式。
• 桥梁模式包括：抽象化角色，修正抽象化角色，实现化角色，具体实现化角色。其中实现化角色和抽象化角色是桥梁模式的关键所在。在抽象化角色中，调用实现化角色定义的方法，（而具体的实现化角色实现实现化角色定义的方法，从而实现抽象化角色接口）。修正抽象化角色扩展抽象化角色方法，但是对具体的实现化角色并不发生影响。其中，实现化角色体现了桥梁的作用，使得抽象化和实例化的脱耦。
• 在Java库的API设计中，Component和ComponentPeer通过ToolKit联系，Component是Java代码，ComponenPeer是本地代码。Component是在调用peer的方法，但是对于Java程序员开发而言，这是透明的，我们仍然是对Component操作。Component就是抽象化角色，ComponentPeer就是实现化角色。
• 我的理解2，桥梁模式其实是解决系统的两个变化而生成的一种模式。一方面，抽象接口在变化，一方面，具体实现也在变化。要解决变化对系统带来的影响，我们引入桥梁模式。在桥梁模式下，抽象接口的变化和具体实现的变化几乎可以视作两个系统的变化。
• 我的理解3：原有的实现是具体实现实现抽象接口，是一个继承的关系。是紧耦合的。而桥梁模式是采用聚合的关系。桥梁模式可能是设计模式中集大成者。需要对系统设计有一定的造诣，才能完美应用之。
• 好的设计，系统的继承关系不超过2层。
• 八戒投胎，灵魂，天蓬元帅，肉体，猪头就是桥梁模式的一个应用
• 使用桥梁模式的场景：系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，系统要求实现化角色的改变不影响客户端，一个构件有多余一个的抽象化和实现化角色，设计要求独立管理抽象化和实现化角色