引出话题
某气象局在当地部署了大量的温度感知设备，该设备可以收集周围的温度，并将数据定时上传到后台数据处理中心。设备和后台的通信格式采用json，它们通信的流程是：1、设备首先向后台发送校时请求报文（{"type":1}），后台收到后获取本地时间并回复校时报文（示例：{“type”:2, "time":"2019-09-09 00:00:00"}），感知设备收到校时回复后解析出里面的时间用于同步设备时间；2、校时成功后，设备每隔1分钟向后台发送一次心跳报文（示例：{"type":3, "time":"2019-09-09 01:00:00"}），后台以此报文来判断设备的状态，如果长时间收不到某台设备的心跳，就派人前去维修；3、设备每隔10分钟上传一次周围的温度（报文示例：{"type":4, "temperature":26.5, "time":"2019-09-09 02:30:00"}）；现在你的任务是设计后台程序，将设备上传的所有数据保存下来。
第一手代码
分析与设计
设备有3种类型的报文，所以当有报文到达时，后台应首先解析出报文的类型，然后根据类型分别作不同的处理。
编码实现
/**
* 处理报文
* @param msg 报文实体类
*/
public static void handlerMsg(Msg msg) {
if(1 == msg.getType()){
handlerCalibrateTime(msg);
} else if(2 == msg.getType()){
handlerHeart(msg);
} else if(3 == msg.getType()){
handlerData(msg);
} else {
System.out.println("无法识别的报文类型");
}
}
public static void main(String[] args) {
//模拟校时请求报文（这里为了方便，默认已将json转为实体类）
Msg msg = new Msg();
msg.setType(1);
handlerMsg(msg);
}
功能算是完成了，现在我来分析这样设计的缺陷：
1、handlerMsg()方法中存在if/else语句，目前的逻辑判断还不算复杂，但是在实际工作中，感知设备与后台交互的报文远远不止这3种，比如上传设备硬件状态报文、硬件告警报文等等。那么照目前的设计思路，只有后台需要多掌握一点信息，就需要修改handlerMsg()方法中的逻辑判断，首先违背了开闭原则，其次这种修改非常容易造成之前经过测试的代码出现错误；
2、所有类型的报文处理都需要经过handlerMsg()方法，也就是说handlerMsg()方法的职责太大，完全不符合一个函数只做一件事的原则，某个函数承担的责任越大，对它的修改风险就越大；
3、这种设计完全是面向过程设计，也就是函数式编程，没有一点面向对象思维！
设计模式
