我想实现一个实际上包含3的系统，每个系统的功能因用户角色类型而异。即允许用户根据角色类型执行不同任务的系统;在用户创建时确定的角色类型。用户无法使用他们的角色访问系统的其他组件/功能，并且UI对每个用户都是唯一的。*
我需要这些“系统”彼此独立行动，但我发现了一些共同的行为（最常见的是组合的机会）。
目前，我有3个控制器，因为这是我设计的初衷 - RoleType1Controller，RoleType2Controller，RoleType3Controller。显然，这些分支独立，并触及他们需要触摸的类。
我正准备在功能上做一些相当大的增强功能，一旦我站起来并需要考虑这些增强功能，因为其中一些将是系统的共同驱动点。即我希望系统做一些同样重要的事情，但目前只能实现一个主要功能。
关于OOD，我认为这种“三合一系统”方法可能最适合即将发生的变化。然而，这些组合机会以及与单一控制器标准保持一致的愿望正在严重影响我的决策过程。
有没有人有过这样的经历，或者，如果没有，在OOD中有经验，可以指出我正确的方向吗？我正在从头开始构建，所以（显然）系统的框架正在第一次迭代中定义。我希望它尽可能强大和灵活。
非常感谢任何帮助。
*我没有使用UI来推动我的设计过程......我只是觉得这些额外的信息可能会有所帮助。
答案 0 :(得分：0)
在这种情况下，答案是拥有多个控制器。不一定是角色（尽管这是我的域模型当前形成的方式）;这些应该通过委派用例控制器责任的过程来定义。我在设计的初始阶段找到了这个 - 定义SSD和类图。
在应用UML和模式：面向对象的分析和设计和迭代开发简介（一本令人难以置信的介绍性书籍，从各种经过验证的最佳实践定义及其作者中提取其背景），Craig Larman说明有两种方法来定义控制器：
将责任分配给代表以下选项之一的类：
•表示整个“系统”，“根对象”，软件在其中运行的设备，或主要 子系统 - 这些都是外观控制器的变种。
•表示发生系统事件的用例场景，通常名为Handler， 协调员或会话（用例或会话控制器）。
•对同一用例场景中的所有系统事件使用相同的控制器类。
•非正式地，会话是与演员对话的实例。会话可以是任何长度，但是 通常按用例（用例会话）组织。
以前的经验总是引导我找到第一个解决方案，因为我帮助设计的系统的复杂程度要低得多。但是，我遇到了这个问题：臃肿的控制器。
Larman在同一文本中提出了这个建议：
问题和解决方案
设计不良，控制器类具有低凝聚力 - 没有重点，处理太多责任区; 这被称为臃肿的控制器。腹胀的迹象是：
•只有一个控制器类接收系统中的所有系统事件，其中有很多。 如果选择了外观控制器，有时会发生这种情况。
•控制器本身执行完成系统事件所需的许多任务，而无需委托 工作。这通常涉及违反信息专家和高凝聚力。
•控制器具有许多属性，它维护有关系统或域的重要信息，这些信息应该已分发给其他对象，或者复制其他位置的信息。 对于臃肿控制器的治疗方法有两个：
- 添加更多控制器 - 系统不必只需要一个。而不是外观控制器，使用用例控制器。 例如，考虑具有许多系统事件的应用程序，例如航空公司预订系统。它可能包含以下控制器：
用例控制器
MakeReservationHandler
用例控制器
ManageSchedulesHandler
ManageFaresHandler
- 设计控制器，使其主要委派每个系统操作职责的履行 到其他物体。
2）本身并没有帮助我，因为我让演员们以同样的方式对同一个班级说话......我已经尽力将责任委托给其他班级，同时努力维持为用户提供简单而一致的交互。如前所述，这引导我进入臃肿的控制器＆＃34;问题。
因为OOA / D是一个不断发展的过程，所以我不能说这是我的最终解决方案，直到它真正实施。实际上，这些用例控制器可能会让我走上一条不同的路径...而不是（比如）每个（例如）用例的控制器，我最终会得到3（或4或5或6），这可能只是到达那里的方法。但就目前而言，情况比以前更顺利 - 我开始看到最终解决方案的实现。