問題描述

場(chǎng)景如下： 客戶會(huì)通過sdk傳過來原始消息，我現(xiàn)在開發(fā)的模塊收到消息后會(huì)根據(jù)配置對(duì)該消息進(jìn)行提取和轉(zhuǎn)換生成新的消息格式，并通過mq傳給下游模塊。

如果套用一個(gè)模式的話應(yīng)該是用什么呢？

編輯于：2017年6月22日 18:00

可能我沒有描述清楚，導(dǎo)致大家誤解了，詳細(xì)描述一下場(chǎng)景：

接收消息

判斷該消息是從哪個(gè)客戶發(fā)過來的，并取出該客戶在后臺(tái)的配置

根據(jù)配置信息，進(jìn)行消息的提取和轉(zhuǎn)換，生成新格式的消息

把新消息發(fā)送給后端其他模塊進(jìn)行處理

問題解答

你所完成的功能是一個(gè)轉(zhuǎn)換器，限定死要求來的數(shù)據(jù)的格式，譬如id,type,content，你可以寫一個(gè)接口，擁有g(shù)etId,getType,getContent方法，要求實(shí)現(xiàn)方必須提供這幾個(gè)值。經(jīng)過你的轉(zhuǎn)換器后，得到不同的對(duì)象。

我想可以這樣來實(shí)現(xiàn)：

針對(duì)不同的消息，有不同的消息處理器（Handler）來完成對(duì)應(yīng)的功能，消息提取和新消息的生成等；

這些Handler實(shí)現(xiàn)了一個(gè)共同的接口，后續(xù)還可以繼續(xù)增加新的Handler；

所有Handler形成一個(gè)處理鏈，每個(gè)Handler有個(gè)match方法來判斷是否該由自己處理，不能處理的，交給后續(xù)的Handler。

所以我覺得可以考慮責(zé)任鏈模式，策略模式等。

這么簡(jiǎn)單的需求，adapter，適配一下就可以了