场景
商城系统中常见的商品分类,以电脑为例,如何良好的处理商品分类销售的问题?
-
下图的关系我们可以用多继承结构来实现
package bridge;
public interface Computer {
void sale();
}
class Desktop implements Computer{
public void sale() {
System.out.println("销售台式机!");
}
}
class Laptop implements Computer{
public void sale() {
System.out.println("销售笔记本!");
}
}
class Pad implements Computer{
public void sale() {
System.out.println("销售平板!");
}
}
class LenovoDesktop extends Desktop{
@Override
public void sale() {
System.out.println("销售联想台式机!");
}
}
class LenovoLaptop extends Laptop{
@Override
public void sale() {
System.out.println("销售联想笔记本!");
}
}
class LenovoPad extends Pad{
@Override
public void sale() {
System.out.println("销售联想平板!");
}
}
class DellDesktop extends Desktop{
@Override
public void sale() {
System.out.println("销售戴尔台式机!");
}
}
class DellLaptop extends Laptop{
@Override
public void sale() {
System.out.println("销售戴尔笔记本!");
}
}
class DellPad extends Pad{
@Override
public void sale() {
System.out.println("销售戴尔平板!");
}
}
class HpDesktop extends Desktop{
@Override
public void sale() {
System.out.println("销售惠普台式机!");
}
}
class HpLaptop extends Laptop{
@Override
public void sale() {
System.out.println("销售惠普笔记本!");
}
}
class HpPad extends Pad{
@Override
public void sale() {
System.out.println("销售惠普平板!");
}
}
问题
- 扩展性问题(类个数膨胀问题):
如果要增加一个新的电脑类型:智能手机,则要增加各个品牌下面的类。
如果要增加一个新的品牌,也要增加各种电脑类型的类。 - 违反单一职责原则:
一个类:比如联想笔记本,有两个引起这个类变化的原因(品牌和电脑类型)
场景分析
商城系统中常见的商品分类,以电脑为例,如何良好的处理商品分类销售的问题?
这个场景中有两个变化的维度:电脑类型、电脑品牌。
桥接模式核心要点:
处理多继承结构,处理多维度变化的场景,将各个维度设计成独立的继承结构,使各个维度可以独立的扩展在抽象层建立关联。
桥接模式
package bridge;
public interface Brand{
void sale();
}
class Lenovo implements Brand{
public void sale() {
System.out.println("销售联想");
}
}
class Dell implements Brand{
public void sale() {
System.out.println("销售戴尔");
}
}
package bridge;
public abstract class Computer2 {
protected Brand brand;
public Computer2(Brand brand) {
this.brand = brand;
}
public abstract void sale();
}
class Desktop2 extends Computer2{
public Desktop2(Brand brand) {
super(brand);
}
@Override
public void sale() {
brand.sale();
System.out.println("销售台式机");
}
}
class Laptop2 extends Computer2{
public Laptop2(Brand brand) {
super(brand);
}
@Override
public void sale() {
brand.sale();
System.out.println("销售笔记本");
}
}
package bridge;
public class Client {
public static void main(String[] args) {
Computer2 computer = new Laptop2(new Lenovo());
computer.sale();
}
}
输出:
销售联想
销售笔记本
桥接模式总结
- 桥接模式可以取代多层继承的方案。多层继承违背了单一职责原则，复用性较差，类的个数也非常多。桥接模式可以极大的减少子类的个数，从而降低管理和维护的成本。
- 桥接模式极大的提高了系统可扩展性，在两个变化维度中任意扩展一个维度，都不需要修改原有的系统，符合开闭原则。
- 虽然面向对象的继承，功能强大，但并不意味着只要可以用，我们就用上继承，事实上很多情况下继承会带来麻烦。比如，对象的继承关系是在编译时就定义好了，所以无法在运行时改变从父类继承的实现。子类的实现与它的父类有非常紧密的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化。当你需要复用子类时，如果继承下来的实现不适合解决新的问题，则父类必然重写或被其他更适合的类替换。这种依赖关系限制了灵活性并最终限制了复用性。
- 合成/聚合复用原则，合成和聚合都是关联的特殊种类。聚合表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分；合成则是一种强的‘拥有’关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。
合成/聚合复用原则的好处是,优先使用对象的合成/聚合将有助于你保持每个类被封装,并被集中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。（java编程思想在讨论组合与继承时，也建议慎用继承，其使用场合仅限于你确信使用该技术确实有效的情况。到底使用组合还是用继承，一个最清晰的判断方法就是问一问自己使用该技术是否需要从新类向基类进行向上转型。如果必须向上转型，则继承是必要的；但如果不需要，则应当好好考虑自己是否需要继承。）
桥接模式实际开发中应用场景
- JDBC驱动程序
- AWT中的Peer架构
- 银行日志管理：
格式分类：操作日志、交易日志、异常日志
距离分类：本地记录日志、异地记录日志 - 人力资源系统中的奖金计算模块：
奖金分类：个人奖金、团体奖金、激励奖金
部门分类：人事部门、销售部门、研发部门 - OA系统中的消息处理：
业务类型：普通消息、加急消息、特急消息
发送消息方式：系统内消息、手机短信、邮件
