将一个庞大的“单片”课堂分解为更小的课堂

将大型“单片”课堂分成更小的课堂最好的方法是什么？将一个庞大的“单片”课堂分解为更小的课堂

我设计了一个简单的聊天系统，有User对象和Channel对象，用户可以在多个通道中进行通话。

这是我设计的示意图：

UML chat design diagram

主要的问题我有这样的设计是，ChatManager类是位单芯片，即它的东西太多了。在之前的化身中，它也处理了渠道成员资格，现已将其分离为ChannelMembershipManager。

什么是最好的方式去“简化”我的ChatManager类？我的设计有没有其他问题，我没有看到？

来源

2016-05-14 Jack Wilsdon

似乎是合理的。顶级经理班往往有点丑陋。 –

是的，我在reddit上问了一下，很遗憾得到了同样的回应。我只是希望能有些事情可以整理一下。 –

图中没有什么明显的错误。编码并寻找重构机会。 –

根据面向对象原则，打破单体管理器的最佳方式是将职责分配给类。以下是一些立即想到的建议。不要指望完美，这只是我的头顶。

我认为没有必要为“经理”级，虽然我做认为有必要跟踪Channel类的所有实例和User类的所有实例。也许这可以通过每个类中的类静态来完成。（这些指标可以在UML用预选赛，这工作有点像哈希地图。该Channels和Users真的甚至不需要数字建模！这些数字仅仅是许多方法来编写这一个。

每User类的实例可以使用命令通道与某个人进行通信当一个人要求User类的实例加入一个通道时，它可以创建一个Private Channel的实例，该实例管理一个专用于每个通道的套接字一个人，然后询问要求的Channel的实例是否允许接受它。那Private Channel可能有方法到poll(),read()和write()。

当User加入或离开时，Channel类的实例应负责通知事情。 Channel类的每个实例都应负责轮询所连接的Private Channel实例，读取消息/命令并采取措施，例如将消息重复发送给所有其他的Private Channels。

这只是我的头顶。如果我花了一些时间思考这个问题，我可能会看到一些潜在的问题或者我可以做出的优化，但是希望这可以为您提供一些关于如何根据面向对象原则拆分“管理器”庞然大物的想法。

来源

2016-05-15 04:08:29

将一个庞大的“单片”课堂分解为更小的课堂

回答

相关问题