重构实践之桥接模式

原重构实践之桥接模式

您目前处于：架构 2017-07-18

设计模式领域驱动设计

张强作者

张强，16年加入京东，目前就职于京东商城京麦平台组，从事京东对外开放平台和服务于第三方入驻商家的相关工作，开源爱好者，对常用开源框架如Spring、Mybatis、Dubbo等有源码级别的了解，热衷于研究各种技术，致力于成为一名有腔调的工程师

系列文章：

• 设计模式基础

• 设计模式中的类关系

• 小谈实践封装与多态

• 浅谈泛型对方法传参的扩展

• Bridge设计模式

• Composite设计模式

• Proxy / Delegate设计模式

• Reactor / Dispatcher设计模式

• 重构实践之责任链模式

• 重构实践之桥接模式

• 策略模式实践

• 责任链模式实践

• 单例模式的常用写法

• 交易系统中的观察者模式

近日，在开发的过程中发现了一个很大的类，有1000+行代码，大部分情况下，一个1000+行代码的类一定是做了一些本不应该是它负责的事，这是一个处理订单的类，方法大多数是对各种订单消息的处理：

各个Listener（消息监听器）实现接口MessageListener的onMessage方法来接受消息，然后调用服务处理消息，以上结构有三个缺点：

第一、接受消息的代码（如日志、异常处理、监控、遍历）是重复的

第二、Listener（消息监听器）与服务直接耦合

第三、处理消息的服务不够明确，直接导致一个臃肿类的出现

重构开始，首先抽象消息接受模版，解决重复代码问题，然后定义”桥”来连接Listener（消息监听器）和服务：

MessageResolver（消息处理器）作为”桥”，将抽象与实现解耦，Resolver对于Listener是透明的，Resolver的变化不会影响到Listener，具有良好的扩展性，实现代码如下：

abstract class AbstractListener implements MessageListener {
	//实现接口的方法接受消息
	void onMessage(List<Message> msgList) {
		log(); //日志
		ump(); //监控
		try {
            //遍历
			foreach {
				getMessageResolver.resolve(message);
			}
		} catch(...) {

		}
	}
	abstract MessageResolver getMessageResolver(message);
}

interface MessageResolver {
	void resolve(message);
}

class OrderSubmitMessageListener extends AbstractListener {
	MessageResolver getMessageResolver() {
		return OrderMessageResolver;
	}
}

class OrderSubmitMessageResolver implements MessageResolver {
	resolve(message) {
		//消息处理逻辑
	}
}

class PayResultListener extends AbstractListener {
	MessageResolver getMessageResolver() {
		return PayResultResolver;
	}
}

class PayResultResolver implements MessageResolver {
	resolve(message) {
		//消息处理逻辑
	}
}

最后，写一点自己的代码结构的看法，作为一个有腔调的工程师，我们要把我们写过的代码当做一件艺术品，不要放过上面任何的一点瑕疵，有“代码洁癖”完全不是一件坏事，在仔细雕琢的过程中，我们会有很多收获，也会让自己更好的成长。

本文受原创保护，未经作者授权，禁止转载。 linkedkeeper.com (文／张强) ©著作权归作者所有