這個消息類有一個好的設計模式嗎？

Question

這是否有一個好的設計模式？

我想創建一個消息類。

類將被傳遞：

• 消息的類型（例如註冊，註冊確認，密碼提示等）
• 客戶的ID

類需要再看看在數據庫中設置客戶端的消息偏好（無論他們想通過電子郵件，短信還是兩者進行通信）

然後根據客戶的偏好，它將格式化e短信（短版短信，電子郵件長表），並通過我們的郵件或短信提供商的API發送。

因爲我們希望能夠更改電子郵件和短信提供商，如果需要的事實我想知道如果命令模式將是一個不錯的選擇。

感謝您的任何反饋意見。

Answer 1

我不確定你需要這種模式。這聽起來更像是對實際消息發送的抽象方法的簡單繼承。

考慮更好地分配任務。也許使用戶ID負責查找偏好設置，或者爲它編寫第三類。

如果您想使用設計模式，那麼Builder可能適用於構建實際消息。這取決於您是否需要針對不同的消息傳遞方法使用不同的格式。