關於"短信處理"模式的一段討論

時間 2019-11-12

標籤關於短信處理模式一段討論简体版

原文原文鏈接

DH web

請教下你們一個設計模式的問題 spring

業務：有多種短信指令，系統會根據接收到的指令進行相應的業務處理，處理完成後，系統會回覆一條短信設計模式

這種業務處理，能夠用哪一個設計模式來作？多線程

QX app

狀態模式函數

DH 工具

小雪，短信指令可能會增長，也可能會減小性能

QB this

命令模式 spa

用命令模式更合適？

命令模式看起來挺奇怪的。

interface ICommand{
ICommandResult Execute();
}

abstract class CommandResult{
virtual ToString();
}

如何理解

public class Invoker
{
void Invoke(ICommand cmd)
{
CommandResult ret = cmd.Execute();
MessageSender.Send(ret)
}
}

我以爲若是是同步模式話用這種方式就能夠了。很差說是什麼設計模式。

interface ICommand{
CommandResult Execute();
}

敲錯了，qq敲代碼蛋疼。

我再說下業務, 系統接收到上行短信後，會把短信push入消息隊列，有一個線程在監聽消息隊列，每pop出一條消息，都會判斷這條消息是什麼指令，不一樣指令處理不一樣業務

能夠用個工廠模式來建立消息。HandlerFactory，webserver裏面基本上是這樣處理的。

.aspx .ashx .asmx 不一樣的擴展名經過HttpHandlerFactory 建立不一樣的Handler

消息類型的判斷是放在工廠裏作仍是放在監聽消息隊列的線程來作？

Factory裏面來作

if(aspx)
return aspxHandler;
else if
....

STST

這種方式,若是分支的數量自己就不穩定,那麼維護起來不方便

若是性能要求不高的話能夠用反射。

可是若是要求性能的話也只是修改一個類。能夠接受。

指令通常都是固定那些

應該不會怎麼變

STST

儘可能避免修改一個類

這個仍是看項目取捨吧。用反射來處理能夠作到只修改配置文件。

目前有11個指令類型，在想着怎麼優雅的不須要寫分支

STST

具體到這個例子,應該是工廠加職責鏈處理起來比較合適,我的認爲

用map
HandlerMap(string cmdString, Type handlerType)

若是對多線程比較擅長，handler 作成單例的也能夠。

可是我以爲11個指令你就if else 簡單有效。性能也無可挑剔

STST
爲何會想到職責鏈的？

STST

18:47:35

這裏的每一個職責就是每一個相應的業務處理

而後就只要把這些職責串起來,最好把業務量最多的職責放前面

若是須要對命令進行一些過濾操做的話能夠考慮責任鏈。若是隻是單純處理就不須要了。仍是看業務須要。

STST

而後用一個工廠,負責建立職責鏈

這樣處理知足了OCP原則

若是之後增長了業務處理,那麼咱們須要增長一個職責
而後增長一個新的Factory20150405,負責建立新的職責鏈

不用去修改現有的類

也是要改代碼的

STST

這只是個人見解，不用改代碼阿，只增長代碼

你新增了一個Factory 應該在程序裏面去調用他啊

STST

使用那個Factory能夠在配製文件裏處理了

IOC的核心就是這個

選擇哪一個具體的工廠，能夠放配置文件裏處理的

這裏也同時知足了DIP原則，底層依賴了高層

高層不依賴底層

那你至關於要弄一個抽象工廠，我以爲不須要。簡單工廠就能夠了。抽象工廠的話要多很多類哦

STST

能夠這麼理解吧

@大模式-廣州，這圖畫出來理解了嗎？

謝謝各位

我先看下

STST

針對一條短信X

再也不關心是什麼命令，直接丟給職責鏈表來處理

職責鏈表.Do(X)

每一個職責裏的處理方法象下面這樣
Do(X)
{
if(須要本身處理(X)){具體處理;......}
else
Next.Do(X);
}

修改一下

STST

這樣處理沒法知足OCP原則

若是用反射的話是能夠的。

STST

來了新的短信類型一定要修改

不須要，我先寫幾句僞代碼

英界爾，你的圖是用什麼工具畫的，感受挺漂亮的

STST

VISIO?

STST

visual studio

哦哦

STST

public interface IHandler
{
void Handle();
}

public class ConcreteHandlerA : IHandler
{
public void Handle()
{
// handle commandA
}
}

public class ConcreteHandlerB : IHandler
{
public void Handle()
{
// handle commandB
}
}

public static class HandlerFactory
{
public static IHandler CreateHandler(string commandType)
{
switch (commandType)
{
case "A":
return new ConcreteHandlerA();
case "B":
return new ConcreteHandlerB();
default:
throw new NotSupportedException();
}
}
}

public class CommandParser
{
public void Receive(string msg)
{
Command cmd = this.ParseCommand(msg);

IHandler handler = HandlerFactory.CreateHandler(cmd.CommandType);
handler.Handle();
}
}

STST

問題就在這裏，來了C，D，E，F呢

罩門在HandlerFactory 增長新的command 只須要修改HandlerFactory。

可是若是在HandlerFactory中用反射的話就能夠作到不修改代碼。

性能與優雅的取捨。

要優雅就用反射。要性能就用switch case

你的方法也避免不了這個問題。

罩門是同樣的

STST

這一過程，有反射的話如何寫？

責任鏈比較適合要對一個命令分別處理
好比HttpModule 或 Filter之類的。

假設配置文件中已經把 commandType與handlerType作好映射。

像STST說的那種方案，能否經過Spring配置來避免後續修改代碼問題

string typeName = Configuration.GetTypeName(commandType);
Type handlerType = Type.GetType(typeName);
return (IHandler)Activator.CreateInstance(handlerType);

STST

@大模式-廣州那就是IOC

是的。由於這種問題不用反射無解。必需要修改代碼。

STST

看修改的是那裏的代碼，修改最頂層的代碼代價很小，修改下面的代價較大

這裏不管是哪一種方案，都在努力作一件事情，將對"具體"的瞭解儘可能網高層推

最理想的狀況下，只有main函數須要知道全部的"具體"類

哈哈那就是標準的IOC了。

在Main裏面作各類Mapping

直接IOC是否是能夠解決修改代碼的問題，後續只要增長短信類型便可

也是須要作映射的，可是通常IOC容器都支持配置文件，可使用配置文件進行映射。

STST