重构实践之桥接模式
|
您目前处于：Architecture
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 (文／张强) ©著作权归作者所有 |
7631
阅读数
视频课程
好文推荐