控制类用于在系统中协调行为。系统可以在没有控制对象的情况下执行某些用例（仅使用实体对象和边界对象），尤其是那些只需对已存储信息进行简单处理的用例。

较复杂的用例一般都需要一个或多个控制类来协调系统中其他对象的行为。控制对象的示例有：事务管理器、资源协调器和错误处理器。

控制类有效地将边界对象与实体对象分开，让系统更能适应其边界内发生的变更。这些控制类还将用例所特有的行为与实体对象分开，使实体对象在用例和系统中具有更高的复用性。

控制类所提供的行为具有以下特点：

· 独立于环境（不随环境的变更而变更）。

· 确定用例中的控制逻辑（事件顺序）和事务。

· 在实体类的内部结构或行为发生变更的情况下，几乎不会变更。

· 使用或规定若干实体类的内容，因此需要协调这些实体类的行为。

· 不是每次被激活后都以同样的方式执行（事件流具有多种状态）。

确定是否需要控制类

用例的事件流决定了不同任务的执行顺序。首先，调查事件流是否能由已确定的边界类和实体类进行处理。对于主要是为了输入、检索、显示或修改信息的简单事件流来说，通常不必单独使用一个控制类，将由边界类负责协调用例。

如果事件流较复杂，而且包含一些可能会独立于接口（边界类）或系统信息库（实体类）而变更的动态行为，则应该将该事件流封装在一个单独的控制类中。通过封装事件流，同一个控制类就可能由具有不同接口和信息库（或者至少基础数据结构不同）的各种系统重复使用。

示例：管理任务队列

您可从库房管理系统的执行任务用例中确定一个控制类。该控制类处理一个任务队列，保证任务按照正确的顺序来执行。一旦分配好运输工具后，它就执行队列中的下一个任务。因此，系统可以同时执行多个任务。

如果将由其对应的控制对象定义的行为分为两个控制类（Task Performer 和 Queue Handler），那么说明此行为就会更加容易。Queue Handler 对象将只处理队列顺序和对运输工具的分配。整个队列只需一个 Queue Handler 对象。一旦系统要执行某个任务，它就会产生一个新的 Task Performer 对象来执行该任务。所以，系统所执行的每个任务都需要一个 Task Performer 对象。

复杂的类应按照类似职责进行划分

这种划分的主要好处在于：我们将队列处理职责（许多用例中都有的职责）从任务管理的特有活动（该用例所特有）中分离出来。这使得理解类更加容易，而且更易于随着设计的成熟而进行修改。这还有益于保持系统的负载平衡，因为只要有处理负载的需要，就可以创建足够的 Task Performer 来处理工作量。

将主事件流和备选/异常事件流分别封装在不同的控制类中 为了简化变更，将主事件流和备选事件流封装于不同的控制类中。如果备选事件流和异常事件流完全独立，那么将它们也分开。这会方便系统以后的扩展和维护。

如果两个主角共享同一个控制类，则应划分控制类 如果多个主角使用同一个控制类，那么可能也需要划分控制类。通过这种方法，我们将一个主角需求的变更与系统的其他部分隔离开。如果变更成本很高，或后果非常严重，您就应该找出所有与多个主角相关的控制类，并对它们进行划分。理想情况下，每个控制类应该最多只与一个主角进行交互（通过一些边界对象）。

示例：电话通话管理

以用例市内电话为例。我们首先确定一个控制类来管理通话。

用来控制电话系统中市内电话的控制类可以很快地分为两个控制类：A 行为和 B 行为，分别对应于各自的主角。

在市内通话中，有两个主角：拨打电话的 A 用户和接听电话的 B 用户。A 用户拿起话筒，听到拨号音，然后拨打电话号码。系统立即存储号码并进行分析。系统接收到号码的所有数字后，将振铃音发往 A 用户，同时向 B 用户发出振铃信号。B 用户拿起话筒后，振铃音和振铃信号都停止，而这两个用户间的通话就可以开始了。通话直到这两个用户都挂机时停止。

有两种行为必须加以控制：A 用户端行为和 B 用户端行为。出于这个原因，初始控制对象被分为两个控制对象：A 行为和 B 行为。

如果符合以下情况，您就不必划分控制类：

· 您有理由确信，与控制类对象有关的主角的行为绝不会变更或者变更微乎其微。

· 控制类中某个对象对一个主角的行为与它对另一个主角的行为相比根本是无关紧要的，单个对象就可包含所有行为。这种方式的行为组合对可更改性的影响可以忽略不计。