基于角色的面向对象设计-控制器

Question

我想实现一个实际包含3个的系统，每个系统的功能因用户角色类型而异。即，允许用户基于其角色类型执行不同任务的系统；角色类型在用户创建时正确确定。用户不能使用其角色访问系统的其他组件/功能，并且每个用户的UI都是唯一的。*

我需要这些“系统”相互独立地运行，但我发现了一些共同的行为(最常见的是，组合的机会)。

目前，我有3个控制器，因为这是我设计的初衷-- RoleType1Controller，RoleType2Controller，RoleType3Controller。显然，这些分支独立地分支，并接触它们需要接触的类。

一旦我开始工作，我就准备在功能上进行一些相当大的增强，需要考虑这些增强，因为其中一些将是系统的共同驱动点。也就是说，我想让系统做几件事情，所有的事情都是同等重要的，但目前只能实现一个主要功能。

关于OOD，我认为这种“三系统合一”的方法可能最适合即将到来的变化。然而，这些组合的机会和保持拥有单一控制器的标准的愿望对我的决策过程产生了很大的影响。

有没有人有这样的经验，或者，如果没有，在面向对象设计方面有经验，可以给我指明正确的方向？我是从头开始构建的，所以(显然)系统的框架是在第一次迭代中定义的。我希望它尽可能的健壮和灵活。

任何帮助都将不胜感激。

*我没有使用UI来驱动我的设计过程...我只是认为这些额外的信息可能会有一些帮助。

Answer 1

在这种情况下，答案是拥有多个控制器。不一定是通过角色(尽管这是我的领域模型当前形成的方式)；这些应该通过委派用例控制器责任的过程来定义。我在设计的初始阶段发现了这一点--定义SSD和类图。

在应用UML和模式: An Introduction to Object-Oriented Analysis and Design and Iterative Development (一本令人难以置信的介绍性书籍，从各种经过验证的最佳实践定义及其作者中提取上下文)中，Craig Larman指出有两种方法来定义您的控制器：

将责任分配给代表以下选项之一的类：

·表示整个“系统”、“根对象”、运行软件的设备或主要子系统--这些都是外观控制器的变体。

·表示发生系统事件的用例场景，通常命名为处理程序、协调器或会话(用例或会话控制器)。

·对相同用例场景中的所有系统事件使用相同的控制器类。

·非正式地说，会话是与参与者对话的实例。会话可以是任意长度的，但通常是根据用例(用例会话)来组织的。

以前的经验总是将我引向第一个解决方案，因为我帮助设计的系统的复杂性要低得多。然而，我遇到了这个问题：臃肿的控制器。

在同一篇文章中，Larman提出了这样的观点：

问题和解决方案

如果设计不佳，控制器类的内聚力就会很低--没有重点，需要处理太多的职责，这就是所谓的臃肿的控制器。肿胀的迹象是：

·只有一个控制器类接收系统中的所有系统事件，而且数量很多。如果选择了外观控制器，则有时会发生这种情况。

·控制器本身执行许多完成系统事件所需的任务，而不委托工作。这通常涉及违反Information Expert和High Cohesion。

·控制器有许多属性，它维护有关系统或域的重要信息，这些信息本应分发给其他对象，或者复制在其他地方找到的信息。解决控制器臃肿的方法有以下两种：

1. 添加更多控制器-一个系统不必只需要一个控制器。而不是外观控制器，使用用例控制器。例如，考虑具有许多系统事件的应用程序，例如机票预订系统。它可能包含以下controllers:

用例控制器

MakeReservationHandler

用例控制器

ManageSchedulesHandler

ManageFaresHandler

1. 设计控制器，使其主要将每个系统操作责任的履行委派给其他对象。

2)本身不会对我有帮助，因为我有演员以自己的方式对相同的类说话……我已经尽可能多地将责任委派给其他类，同时试图为用户保持简单一致的交互。如前所述，这导致了“臃肿的控制器”问题。

因为OOA/D是一个不断发展的过程，所以在它真正实现之前，我不能说这是我的最终解决方案。实际上，这些用例控制器可以为每个用例带来不同的控制器path...instead，我可能最终得到3个(或4个或5个或6个)控制器，这可能只是一种实现方法。但就目前而言，事情比以前顺利得多-我开始看到最终解决方案的实现。