繼承作為添加模塊化能力的一種方式

Question

我打算創建一個簡單的機器人，但不想重做一次，如果將來會變得更復雜。 所以我想知道我的方法將來是否會引起任何問題。 如果有更好的解決方案/方法。

我打算做什么：

• 有一個Communicator類來讀取用戶輸入
• 有一個Ability接收消息和回復消息的基本方法的Ability類
• 項繼承那些Ability與其他所有能力類的類
• 將所有Ability類存儲在主Communicator類的數組/列表中
• 當Communicator收到一條消息時，它會通過調用Communicator類中的方法將其發送到該列表中的所有類以及該命令用於回復的類（將消息發回）。

例子：

• 繼承能力的類： Greet和Backflip
• 用戶輸入： “做一個后空翻”
• “做一個后空翻”被發送到類 Greet 和后空翻。
• 這兩個類都處理字符串
• 后空翻類檢測到后空翻命令並回復“后空翻”

這種解決方案的擴展性如何？ 另一個主要目標是讓其他人更容易實現自己的能力並將它們包含在程序中，類似於Hubot 。

Answer 1

從概念上講，您所描述的與 MVC 沒有太大區別……您的Ability很好地映射到控制器，而回復映射到視圖。 您甚至可以選擇一個 MVC 框架，如 ASP.NET/MVC。

MVC 與您所描述的不同之處在於，通常有某種類型的路由器將傳入命令路由到特定控制器，而不是將消息廣播給所有控制器以決定它們是否可以響應。 廣播你的考慮似乎有點矯枉過正……因為每一個Ability都必須解析並決定做出回應。 這帶來了可擴展性問題……尤其是同時進行的大量對話。

此外，如果一旦您的世界變得龐大而復雜，多種Abilities做出響應，會發生什么？

在 MVC 中，路由器負責將輸入中的模式映射到控制器中預先注冊的或更可能的基於約定的操作。 路由器將具有啟發式（通常是先發現者獲勝）來確定要調用哪個控制器。 框架通常有各種自定義路由器的方法。

除非這只是一個有趣的事情，並且不會被征收重稅，否則您最好調查某種 MVC 框架來為您完成骯臟的工作。