重构实践之桥接模式
您目前处于:编程  2017年07月18日

近日,在开发的过程中发现了一个很大的类,有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 (文/张强)