小谈实践封装与多态
梳理
最近在重构一段代码,发现之前的流程大概是如下图,这样的设计结构。

一、这是一个发送消息的流程,长长的一段代码,通过依赖构成整个流程的架构。整个流程依赖三个环节:适配、发送、保存,其中发送又依赖消息体生成。
二、由于消息类型不同,适配、发送、保存的具体实现不同,所以代码中大量的充斥着if ... else ...的判断语句。
这不仅导致代码可读性很差,而且还产生了大量冗余代码。
重构
针对如上问题,首先是通过组合的方式重新封装。

一、提取一个更高的抽象(Mesasge),这里组合了Sender和Saver两个行为,这里只组合行为,不组合实现。
这样的好处,是外观代码变得更加清晰,如下面代码:
Message message = adapterService.adapter(jsonMessage);
message.getSender().send();
message.getSaver().save();
之前和同事讨论这里,很形象的比如成,Sender像一张弓,Message像一支箭,getSender()可以获取不同的弓,Message也可以是不同的箭,通过不同的实现随意组合。
This chapter requires login to view full content. You are viewing a preview.
Login to View Full Content