將大型「單片」課堂分成更小的課堂最好的方法是什麼？將一個龐大的「單片」課堂分解爲更小的課堂
我設計了一個簡單的聊天系統，有User對象和Channel對象，用戶可以在多個通道中進行通話。
這是我設計的示意圖：
主要的問題我有這樣的設計是，ChatManager類是位單芯片，即它的東西太多了。在之前的化身中，它也處理了渠道成員資格，現已將其分離爲ChannelMembershipManager。
什麼是最好的方式去「簡化」我的ChatManager類？我的設計有沒有其他問題，我沒有看到？
根據面向對象原則，打破單體管理器的最佳方式是將職責分配給類。以下是一些立即想到的建議。不要指望完美，這只是我的頭頂。
我認爲沒有必要爲「經理」級，雖然我做認爲有必要跟蹤Channel類的所有實例和User類的所有實例。 也許這可以通過每個類中的類靜態來完成。 （這些指標可以在UML用預選賽，這工作有點像哈希地圖。該Channels和Users真的甚至不需要數字建模！這些數字僅僅是許多方法來編寫這一個。
每User類的實例可以使用命令通道與某個人進行通信當一個人要求User類的實例加入一個通道時，它可以創建一個Private Channel的實例，該實例管理一個專用於每個通道的套接字一個人，然後詢問要求的Channel的實例是否允許接受它。那Private Channel可能有方法到poll(),read()和write()。
當User加入或離開時，Channel類的實例應負責通知事情。 Channel類的每個實例都應負責輪詢所連接的Private Channel實例，讀取消息/命令並採取措施，例如將消息重複發送給所有其他的Private Channels。
這只是我的頭頂。如果我花了一些時間思考這個問題，我可能會看到一些潛在的問題或者我可以做出的優化，但是希望這可以爲您提供一些關於如何根據面向對象原則拆分「管理器」龐然大物的想法。
似乎是合理的。頂級經理班往往有點醜陋。 –
是的，我在reddit上問了一下，很遺憾得到了同樣的迴應。我只是希望能有些事情可以整理一下。 –
圖中沒有什麼明顯的錯誤。編碼並尋找重構機會。 –