为AOP注入团队活力(4)

第二个模式类似设计代码库的状况：一个模块实现了一套丰富功能，而应用仅能使用其中一部分。但是，在这个重用Aspect的案例中没有提供通过明确方法调用来选择特性的主程序。

在我们的安全案例研究中，我们在为了支持某个logout操作而适配某个部署GUI时发现这一情况：不同元素（比如菜单项或者logout按钮）需要被添加到GUI中。这里存在着两种可能的实现：在抽象层实现和在具体的logout team实现。

这个问题在Object Team中很容易被解决。抽象team实现所有的功能：增加按钮和菜单项。而subteam：LogoutOptionTeam可以自由地选择绑定该使用的方法。例如：callin绑定将只导致按钮为添加到GUI。因为addMenuItem方法是未经绑定的，所以它将不被调用。

这里存在着部分绑定role行为所带来的好处：所有的行为在抽象层实现，实现对在bese系统进行具体适配的抽象类的使用可以通过简单地绑定方法或者不绑定方法来进行功能选择。如果使用全部功能，则role方法将被同一的base方法绑定（本例中的add方法被initializeGUI方法绑定）。

统一role访问：

图5：统一role访问

这便是依靠实现抽象接口的面向对象风格与明确引用接口的实现相比之下的更妙之处。使用Object Teams，可以通过两种不同方式提供在抽象接口后面的实现：通过直接实现功能或者使用callout绑定方式委托调用给被适配的base对象。基于直接实现和委托抽象role方法这两种选择的比较，后者不但能将如何实现恰当的行为进行抽象，而且将此行为被实现的位置进行抽象。在这种抽象role的可以进行是完全自由地选择或者结合这两种技术来实现其行为。

上述两种行为能够以一种统一的方式被访问到。图-5展现了我们在安全案例中是如何统一访问role行为的。LogoutOptionTeam负责logout选项。ViewAdapter作为这个team的role，负责为指定的部署视图添加按钮。为了实现添加按钮的功能，一套helper方法被抽象地声明在superrole中，并且在subroles中被改进。例子中展示了这些方法中的两个：getRootPane方法返回部署视图的root pane，getRessources方法返回被用到的资源包。这两个方法被定义在同一个role中，并且能在role实例中被调用，只是其行为不同。

第一个方法getRootPane是被委托到返回root pane的被适配的视图对象。第二个方法则完全在role中实现，不需要来自base对象的信息。

统一role的访问将role方法的调用者从如何提供实现的设计烦恼中解放了出来。具体层的开发者能决定是否在role中实现接口还是委托到base对象。这两种实现接口的方式也可以被混合使用。

提醒者roles（Reminder roles）：

当我们实现了抽象层，我们不得不决定如何处理那些可能访问某个指定team的环境，但却没有功能或者没有在抽象层的参考。如果我们不给出在抽象team中的一个提示，那么具体层的开发者将忘记或者对role产生困惑并相信这种role是不重要的。或者，我们能实现这样的空白role，但在本例中，我们不得不解释一下：这种role没有行为和依赖。

我们建议选择后者，我们称这些空白的role为“提醒者roles”。它们的目的是提醒开发者：这里存在一些需要在具体层实现的role。提醒者role是普通的、空白的role。如果我们想在subteam中强制实现它们，那么就需要声明它们为抽象并且尽可能地具体化提醒者role，使得subteam中无需再实现。这里我们发现提醒者role并不是一种技术而是一种有方法论的解决方案。

六、重用的可行性研究

同时，一个与安全案例相独立的、用于测试Aspect重用可行性的比较性案例研究正在进行着。这个研究分享了一些安全案例中的基本推断。比如：使用TOPPrax的部署系统作为研究的base应用、着眼于安全Aspect。但与本文中的安全案例不同的是它的范围和目标。作为一种可用性研究，其着眼点更偏重于探索而不是如何交付产品。通过可行性研究，我们评估概念性和技术性的成熟度，尤其是在base应用中的Aspect重用。一些在语言和工具上的提升已经通过这个研究被模拟出来。在这一研究的过程中，一套抽象的Aspect被设计和实现。这一问题域包括：如何在没有传播用户周围环境信息功能的base应用中提供此信息、在base应用中实现统一访问的会话Aspect。这个Aspect通过基本认证和授权的Aspect来完成。

控制roles：

在设计可用性研究的Aspect集合时，需求导致允许Aspect被描述为两个不同方向。

1．在相互协作的Aspect之间的耦合。
2．对具体base应用的适配。