一旦发现真正要解决的问题，就可以开始“压缩”解决方案，形 成一个越来越密集的在此起决定作用的模式场。

设计造成的模式密集

将测试用例确定为关键抽象并使用 Command 封装它之后， Cook''s Tour 进一步确定了新的需求，为表示这一关键抽象的对象增加了新 的特性。下面的图示对此做作了很好的说明：

图 1. JUnit 模式框图

Gamma 和 Beck 遵循了（或者应该说指引着）现在的标准设计过程 ：发现关键抽象，并将它们封装到对象中，添加模式来安排对象担任的角色和提 供的服务。不幸的是，正是这些造成了模式密集。关键抽象的职责和关系在不断 增加，直到像步入中年的父母一样只能按照老套的习惯行事。（如果需求超过了 它们的能力，那么它们随后会陷入困境。）

给定一个测试用例……

AOP 提供了描述抽象的另一种方法：说明连接点的切入点。连接点 是程序执 行中可以有效连接行为的点。连接点的类型取决于 AOP 的方式，但所有连接点在 一般程序修改中都应该是稳定的，容易作出有意义的说明。可以使用切入点 指定 程序的连接点，用通知（advice）指定连接的行为。通知就是陈述“如果 X，则 Y”的一种方式。

Command 模式说，“我不关心运行的代码是什么，把它放在该方法中就行了。 ”它要求将代码放在命令类的命令方法中，对于 JUnit 而言，该命令方法是 Test 的 runTest() 方法，如 TestCase：

public class MainTest extends TestCase { 　public void runTest (...) {...} }

AOP@Work: 设计切入点来避免模式密集(3)

相反，切入点说“让某个连接点作为测试用例吧。”它只要求测试用例是某个 连接点。不需要将代码放在特定类的特定方法中，只需要用切入点指定一个测试 用例：

pointcut testCase() : ... ;

比如，可以将测试用例定义为 Runnable.run() 或main 方法，当然也可以使 用 JUnit 测试：

pointcut testCase() : execution(void Runnable+.run()); pointcut testCase() : execution(static void main(String[])); pointcut testCase() : execution(public void Test+.run(TestResult)); pointcut testCase() : execution(public void TestCase+.test*());

切入点的可用性

切入点的可用性非常突出。在这里，只要测试能够被切入点选择，就可以作为 测试用例，即使它不是作为测试编写的。如果能够通过通知而不是通过 API 提供 服务，那么就可以减少开发人员在这些服务上的工作量。

通过 AOP，开发人员不需要做什么就能提供服务。这就产生了一种新的 API 客户机：不需要了解它，但可以为它提供服务，或者说它依赖于该服务。对于一 般的 API，客户机和提供者之间有明确的契约和调用的具体时间。而对于 AOP， 更像是人们依赖于政府的方式：无论叫警察、到 DMV 登记，还是吃饭或者上银行 ，人们都（无论是否意识到）仰仗于规则，在规定好的点（无论是否明确）上操 作。

将 AOP 纳入视野之后，可用性就变成了一个更广泛的连续体，从 API 契约到 基于容器的编程模型，再到 AOP 的多种形式。可用性的问题，也从服务接口对客 户机公开了多少功能，转变成了客户机希望或需要对服务了解多少以及如何选择 （无论是司机、骗子，还是应聘者）。

可重用性

与方法一样，也可以将切入点声明成抽象的；即在通知中使用切入点，但是让 子方面具体声明它。通常，抽象切入点规定的不是具体的时间或地点（如宾夕法 尼亚大道 1600 号，星期二），而是很多人感兴趣的一般事件（如选举

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!