近日，在开发的过程中发现了一个很大的类，有1000+行代码，大部分情况下，一个1000+行代码的类一定是做了一些本不应该是它负责的事，这是一个处理订单的类，方法大多数是对各种订单消息的处理：
各个Listener（消息监听器）实现接口MessageListener的onMessage方法来接受消息，然后调用服务处理消息，以上结构有三个缺点：
第一、接受消息的代码（如日志、异常处理、监控、遍历）是重复的
第二、Listener（消息监听器）与服务直接耦合
第三、处理消息的服务不够明确，直接导致一个臃肿类的出现
重构开始，首先抽象消息接受模版，解决重复代码问题，然后定义”桥”来连接Listener（消息监听器）和服务：
MessageResolver（消息处理器）作为”桥”，将抽象与实现解耦，Resolver对于Listener是透明的，Resolver的变化不会影响到Listener，具有良好的扩展性，实现代码如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
abstract
class
AbstractListener
implements
MessageListener {
void
onMessage(List
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) {
}
}
|
最后，写一点自己的代码结构的看法，作为一个有腔调的工程师，我们要把我们写过的代码当做一件艺术品，不要放过上面任何的一点瑕疵，有“代码洁癖”完全不是一件坏事，在仔细雕琢的过程中，我们会有很多收获，也会让自己更好的成长。
打赏（长按扫二维码）
