AOP软件设计

什么是面向方面的编程？

为何面向方面的软件设计？

术语

关注

视口

关注点分离

人工制品

横切

方面

编织

零件

形式主义

第二节

案例研究

关注

人工制品

横切

方面

AspectJ

加入点

切入点

忠告

结论

参考文献

对象技术难以对涉及全球约束和大流行为行为的问题进行定位，适当分离问题，并应用领域专有知识。

什么是面向方面的编程？

面向方面编程（AOP）提供了拦截代码执行的能力，目的是在一般执行的代码以前，代替或以后插入进程。当您考虑到全部内容，调用方法，从方法返回时，检索或分配值，处理异常，切换上下文等等都由代码执行组成，您能够开始考虑如何使用这样的功能。若是这知足了你的好奇心，那么再不要再看了。可是，这个定义很简单，为何会使用AOP的缘由彻底丧失了。还要警告，这个定义只针对一个特定的实现，在本做者看来，实际上与面向方面的软件设计（或开发，即便首字母缩写相同，这些术语彷佛是可互换的） - AOSD。此外，AOSD自己也是后期编程（POP）技术的一个子集。不幸的是，追求AOP和AOSD让咱们很快失去了一种奇怪的术语和定制语言和扩展的泥潭。本文旨在简要了解AOP而不只仅是AOSD的通常性问题。像许多最近的范例旨在解决复杂软件开发中出现的一些问题，AOSD在实际实现的流出中包含了智慧宝库。本文旨在简要了解AOP而不只仅是AOSD的通常性问题。像许多最近的范例旨在解决复杂软件开发中出现的一些问题，AOSD在实际实现的流出中包含了智慧宝库。本文旨在简要了解AOP而不只仅是AOSD的通常性问题。像许多最近的范例旨在解决复杂软件开发中出现的一些问题，AOSD在实际实现的流出中包含了智慧宝库。

开发更简单的系统的成功致使更大的复杂性的愿望¹

为何面向方面的软件设计？

AOSD的主要缘由是帮助解决凌乱对象架构的问题。AOSD的支持者声称面向对象的程序设计难以处理全球信息。此外，须要多个不一样对象（可能收集到组件中）的功能会致使这些对象/组件之间的相互依赖。这使得应用程序易受依赖对象/组件的实现更改的影响。维护和加强也是问题，由于这些对象/组件之间的交互（不管交互规则是正式仍是非正式编码）一般在包含对象内进行硬编码。若是这是混乱的话，那么在这些陈述中，AOSD术语解释AOSD的缘由是特别避免的。这是故意的，以免把车放在马以前。当AOSD的术语马上陷入AOSD的术语时，试图理解AOSD可能会很是混乱，没有任何词汇表。

当应用程序须要作的事情须要许多不一样对象的参与时，会发生Messy对象体系结构。给定需求规范，面向对象设计（OOD）一般经过肯定支持要求所必需的对象来进行。目标是经过分析需求来划分功能，直到发生足够的抽象（包括其余OOD目标）。在整个过程当中，设计人员常常忽视这样一个事实，即最终这些对象将须要相互交互以知足实际功能的要求。这容易和潜意识地发生，由于需求交互的方式一般与对象交互的方式有根本的不一样。设计模式中描述的概念是尝试正式理解对象交互的问题，并为设计人员提供一些很好理解和支持的方法来解决这个对象的相互依赖性问题。事实上，AOP语言的主要实现，即AspectJ，在很大程度上依赖于观察者的设计模式。然而，AOSD倡导者所提出的批评之一就是，除了太多的设计模式（和不断增加的）外，这些模式一般在设计过程当中“设计得太早”。所以，必须从新设计设计，或者更糟的是，当须要不一样的设计模式时，实施必须从新进行。另外一个批评是设计模式与系统结构之间的相互做用。设计模式不只影响系统架构，但它自己受到系统架构的影响。结果，设计模式在实现中消失，失去了其模块性。这一般会影响可重用性，由于设计模式（可重复使用的组件）和对象模型（另外一个可重复使用的组件）被集成到更加刚性，更少可重用的组件中。

就我的而言，虽然我赞成这个观察的现实，但我不一样意这代表设计模式的概念有一些缺陷。相反，我以为这代表不完整的要求和分析，设计师/开发人员缺少教育和培训，以及项目负责人差（有人应该比其余人更聪明！）。若是你接受这个反驳论证，那么它也会排除AOSD是坏对象架构的前提。另外一个考虑因素是，这些范例都不表示什么时候被使用。许多有用的应用程序，包括基于Web的应用程序（复杂对象相互依赖在页面刷新之间难以维护），不会遇到AOSD尝试解决的问题。AOSD（和相似的范例）只有当应用程序跨越自动化简单任务（例如具备剪切和粘贴和打印功能的简单文本编辑器）之间的边界，并自动执行由多个任务组成的复杂过程（如文字处理器提供嵌入式图形，线条图，拼写检查，布局和格式化工具，协做，安全性和与其余应用程序的集成）。这个边界在何处，什么时候在设计范式中转变，仍然是艺术。个人经验告诉我，模糊的需求，不明确的使用案例和潜在的无限加强是我在项目开始时考虑这些问题的指标，并相应地进行设计。什么时候在设计范式中转变，仍然是艺术。个人经验告诉我，模糊的需求，不明确的用例和潜在的无限加强是我在项目开始时应考虑这些问题的指标，并相应地进行设计。什么时候在设计范式中转变，仍然是艺术。个人经验告诉我，模糊的需求，不明确的用例和潜在的无限加强是我在项目开始时应考虑这些问题的指标，并相应地进行设计。

实践要求是在实现过程当中引入横切的问题¹

术语

到目前为止，我已经避免使用与AOSD / AOP一块儿使用的任何术语，试图坚持以知名的面向对象的术语。至少对术语的初步了解是必要的，若是没有其余缘由，不要在下次面试中抛出一堆流行语。术语的良好定义是至关难以捉摸的，部分缘由是这些术语不是很是精确地使用（所以没有人想要定义它们），AOSD的概念继续发展（所以术语具备新的含义），由于学术界继续表现出在没有周围环境的状况下传达无心义的术语的趋势。

关注

AOSD世界中的一个关注有几个定义，但我最喜欢的是IEEE的定义：“...与系统的开发，运行或任何其余方面有关的兴趣，对于一个或多个利益相关者“。然而，将定义归入现实世界的背景下，这并非颇有帮助，但它确实囊括了应用程序开发的各个阶段，以下所列：

• 要求汇集
• 设计
• 原型制做
• 实施
• 测试
• 交货
• 保养

这些阶段中的每个都是一个或多个方或利益相关者感兴趣的（仅举几例）：

• 客户
• 管理
• 开发团队
• 数据库组
• 图书馆/组件开发人员
• 质量保证小组
• 营销
• 生产
• 文档/帮助创做
• 技术支持
• 应用自己

注意最后一个条目“应用程序自己”。重要的是要意识到应用程序自己是利益相关者，对如下问题有疑虑：

• 安全
• 性能
• 优化
• 准确性
• 数据表示
• 数据流
• 可移植性
• 可追溯性
• 剖析

虽然最后一个关注的问题是由不一样的人“持有”，可是应用自己就对这些问题有利害关系，由于它直接影响到实施和返工问题。不管前端设计工做如何，最后一个类别中的许多问题都不会被揭示，直到大多数组件已经粘合在一块儿而且产品已经完成。所以，90％的工做是在最后10％的发展中完成的。若是AOSD有任何有价值的东西有助于软件开发，事实上它将这些关注点带入了意识，让参与软件生产的整个实体从不一样的角度考虑这些问题。

观点

这个术语在AOSD / AOP圈子中并不常见，但值得一提的是，一个观点是从不一样的角度来看待整个系统的方法，并根据这些立场来肯定问题。软件供应商和客户对软件开发过程有不一样的见解。在这两组中（这并不意味着只有两组），供应商与客户（管理层，会计师，数据输入人员）的观点不一样（管理，工程师，技术支持等） 。我从“办公室女孩”的角度常常处理的一个问题是双重的 - “这很难学习？” 和“谁来提供培训？”。讽刺地，

关注点分离

这是对应用程序开发中存在的问题的分析。每一个利益相关者对他/她/他/她参与申请有不一样的担心。关注问题的分离是一个重要的分析，它肯定了物理实施（见工件）最终涉及多个利益攸关方的领域，不管是部门/组织利益仍是对象。从不一样的角度来看待顾虑，有助于分离问题的过程。当涉及多个利益相关者时，需求一般不会明确规定。相反，需求文件一般会针对具体部门的需求提出疑虑。对象设计也是如此（所以，上面的“it”），其中对象设计从预期输入，产生的输出和操纵方法的角度肯定其关注，而不考虑整个系统。所以，分离不一样的问题（这意味着正确识别它们）在后来肯定应用程序中的实际信息流程（参见横切）是相当重要的一步。

分离关注的目的是肯定以分权方式设计和实施的领域。这容许独立的团队并行工做，并拥有独立和自主的决策过程。即便是简单的应用也能够利用这一律念。例如考虑一个简单的网络消息传递应用程序。该应用程序依赖于网络协议已经彻底独立可靠地开发，所以程序员不须要“关心”他/她本身的这个问题。从不一样的角度来看，若是要在合理的时间内完成工做，大型应用程序（考虑运行航天飞机所需的软件）必须将其问题分解为可管理的“块”。然而，这致使了AOSD试图解决的问题，即从新整合这些单独的关切。在一天结束时（比喻），全部不一样的做品必须以有意义和一致的方式放在一块儿。AOSD是在此过程当中检测问题领域的工具。

人工制品

从AOSD的观点来看，关注一般是概念性的，而“文物”是受到关注的动机的具体建设。这引发了一些混乱，关于何时是一个问题，何时是一个神器。经验法则是，若是它是一个概念（例如，需求属性），那么这是一个问题。若是它是一个具体的结构（例如对象的实现），那么它是一个工件。术语“神器”在AOSD世界中并不经常使用。尽量地，将关注和工件视为单独的实体是有用的，以便二者能够彼此独立地考虑。这有助于设计师独立于对实现（工件）的影响来考虑问题。做为顾问，我发现这种技术是无价的，由于它有助于我识别部门之间的沟通问题，现有的手工流程中的问题，部门/人事目标的冲突等。所以，我常常花费个人一半以上的时间记录和修复与编程彻底无关的过程，全部这些都不须要写一行代码。或者，若是我太快地沉浸在对象（工件）的设计中，我历来没有注意到在不一样的问题之间存在冲突和断开链接，直到我太参与项目设计/实施。那么我必需要么修改设计/实现，强制改变现有的进程，要么二者兼而有之。最终的结果是，我被认为是软件交付迟到的缘由，或者是工人之间的焦虑。经过分别查看问题和工件，在编写一行代码以前，我能够解决设计/实现问题。这种方法的反作用是，经过使扭结过程，一家公司当即开始节省资金。他们认为他们须要一个程序来作到这一点！

将关注和伪影分开的目的之一是帮助建立编程语言（参见下面的“形式主义”），能够在不处理实现（artifact）细节的状况下表明关注点。迄今为止，这是很是有限的。有兴趣的读者应参考AspectJ（Java扩展），Cosmos（建模关注工具）和CoCompose（一种设计方法）。

横切

横切是用于描述应用程序与多个工件接口的实现的术语。（看，咱们如今能够开始使用术语）。因为工件是不一样顾虑的物理实现，所以横切一般涉及试图解决若干问题的操做（或工做流程）。因为表示这些关注的工件一般被实现为自主对象（由于咱们都在尝试促进重用），因此咱们最终会出现凌乱的代码。一般将对象传递到其余对象（void ObjectD::DoSomething(ObjectA* a, ObjectB* b, ObjectC* c)）或经过全局机制（AfxGetMainWnd()）获取。这是AOSD的关键 - 批评面向复杂的实现包含相互依赖关系，使得难以调试，测试，维护和扩展功能。经过明确肯定交叉的时间和地点，AOSD提供了一种识别全局相互依赖关系的机制，从而实现OOD的原则，即模块化和重用。（Eek，我开始听起来像我一直在阅读的文章）。

方面

最后咱们能够解释首字母缩略词AOSD中第一个单词的含义。一个方面只不过是在实现中强制横切的东西。而横切是实施使用多个工件，以执行其任务的过程的，一个方面是这种状况，其中发生这种状况。AOSD是识别方面或技术的技术，其中的实现致使了人造物的横切。这真的意味着需求文件不多将总体性的事情进行规定。相反，需求文件是不一样群体组合的需求的集合，每一个不须要彼此考虑。这种遗漏一般不是' 直到对象设计完成而且将对象耦合在一块儿以执行特定过程（或工做流）的问题才会被发现。我看到不少设计省略了这一步。若是没有省略，那么每一个人都会拿出他们的设计模式书，识别适用的设计模式，以帮助将不一样的对象绑在一块儿，在对象图上绘制更多的对象，每一个人都快乐地开始编码。若是我是奥斯德先生坐在这些设计会议上，我会哭“停下来！” 并耐心地解释，设计的元级别仍然是保持设计模式和对象不被纠缠的必要条件。这也将涉及到指出，大概只有10％（若是这样） 强制横切的方面已经获得了适当的肯定。和，因为大多数语言不直接实现AOSD，所以有必要实现一个正确处理这些方面的框架，从而维护咱们的设计模式和对象的模块化/重用。（应用自动化层有多好！）

不幸的是，在至少有一篇关于分离问题的文章中，做者将“方面”定义为组件的属性。这与更常常遇到的AOSD / AOP定义相冲突。

编织

编织就是用来描述任何用于解决方面问题的解决方案的奇怪术语。（哈，你觉得我不能用那个词）。由于这涉及物理实现（工件），编织解决方案是很是任意的，只要产生的努力创造一个连贯的系统。术语“编织”多是因为使用诸如AspectJ的AOP语言扩展造成的精神图像。回想一下我对AOP的简单定义 - 拦截代码执行的能力，目的是在一般执行的代码以前，以后或以后插入一个进程。AOSD经过注入pre，post和“around”过程，将方面的问题（！）实现“编织”到现有代码中。（换一种说法，

零件

这个术语的定义包括在这里，而不是由于它在AOSD中使用（一般不是这样），而是由于本文使用它。组件在Microsoft开发领域内变得模糊，由于它如今与非平凡的GUI控件有关。为了本文的目的，术语组件被定义为“...封装的自治服务提供者，经过良好指定的接口提供有用的服务，使其存在于更普遍的上下文中，并与其余组件协做实现共同目标。 “ ⁵考虑这个定义，即“...并与其余组件合做”，这意味着在其实现中的横切。嗯

形式主义

一种编程语言 （不，我不是在开玩笑）。

在系统设计中没有适当的关注，管理系统的复杂性，可读性，演进和组成将很难²

案例研究

让咱们看看这是如何工做的，以船厂运营管理为例（个人一个客户）。

关注

一，关于处理零件的通常性陈述。请记住，当我开始看自动化操做时，没有一个以任何一致的方式写下来。这是20年语言“专门知识”的结果，并在数周内口头传达给我。正式的流程，图表等都是彻底缺少的。所以，职业培训费用昂贵，形成了许多错误。我以为有讽刺意味的是，当更换系统是不完美的时候，有人能够从计算机系统要求完美。

做为一个全方位服务的船厂，除了小型内部工做外，客户基本上不得在本身的船上工做。这部分是因为环境法规，部分是由于它增长了利润。客户须要的任何零件都是经过店面进行处理的，除非场地经理另有规定，不然一般以零售价出售。客户经过现金，信用卡，支票或经过海运商店帐户支付零件费用。然而，一般，零件用于在客户的船上执行的全部维修和维护。机师被告知，当院长用某种方式（一般是言语）写出一份订单，由客户受权的工做时，须要在船上完成工做。随着工单在手，机械师开始工做，这可能须要零件。零件有库存，缺货，或是特殊订单。假设该部件库存，机械师将进入零件台并要求必要的部件。在结算时间，全部在各类工单上使用的全部零件均已计价，纳税，并向客户收取费用。偶尔，场地经理会谈谈给客户的特别价格。当客户知道竞争是为了少部分销售时，这种状况常常发生。这几乎老是发生在特殊的订单部分，院长经理知道什么时候发布工单。场地经理还将填写一份材料申请表，指明部分和价格。采购人员负责订购零件，并确保在机械师须要的时候及时进行库存。最后，院长经理常常指出，全部为客户开展的工做都是以折扣结算，或只有某些工单有适用的折扣。不然，该部分在零售店收费。采购部门有兴趣了解哪些工做单位用于哪些工做单，以便从此能更好地估计库存的采购量，而院长经理想知道若是能够采用成本削减措施。船厂还有一名会计师，很是有兴趣了解部件的购买和出售状况，由于船厂目前正在每月进行一次15,000美圆的库存注销 - 部件正在被购买，但彷佛正在消失一个黑洞。固然，业主认为这是员工的盗窃。因为这是一个彻底手动的过程，尝试自动化这些过程的任何软件都必须确保库存被精确记录，而且部件正确地向客户收费。哦，还有一件事 请记住，船厂还拥有和经营几艘船 - 启动人员来往和离开他们的船只，包机船等。这些船也须要修理和维护，零件须要正确计费给船厂本身的帐户为了税收目的。与船厂工做相关的全部部件都以“成本”出售给船厂。这些船还须要维修和保养，部件须要正确计费给船厂本身的税务账目。与船厂工做相关的全部部件都以“成本”出售给船厂。这些船还须要维修和保养，部件须要正确计费给船厂本身的税务账目。与船厂工做相关的全部部件都以“成本”出售给船厂。

在本案例研究的范围内，咱们来看看咱们如何用“关注”来重写这个语句。

院长经理

院长们关心：

1. 与工单相关的折扣
2. 与客户相关的折扣
3. 特殊订单特价
4. 在订单上使用的零件
5. 效率

采购部

采购部门关心：

1. 经过海运商店或零件柜台出售零件时的库存盘点
2. 采购特殊订单部件
3. 库存清点

会计师

会计师关心：

1. 库存水平和价值
2. 每个月15,000美圆的注销
3. 对客户或船厂进行零件的正确计费
4. 税收

账单部

计费部门（或应收帐款）涉及：

1. 为客户为指定时间段内使用的全部零件计费

主人

店主担忧：

1. 员工盗窃

船厂关注

在经过考虑文物（组件，对象和其余结构实现）来混淆问题以前，让咱们来看看本身的问题，看看咱们能够学到什么。会计师（15000美圆注销）和全部者（谁窃取个人东西？）的关注其实是涉及能够应用于任何流程或关注的常见主题的问题：验证，纠错和异常处理。这揭示了一些系统性的问题：

1. 院长经理如何根据物料要求验证客户是否正确计费？
2. 谁验证库存是否正确从库存中扣除？
3. 谁验证零件，特殊订单是否正确添加到工单？
4. 谁负责肯定零售价格并采起折扣？
5. 当院长经理忘记通知这个“魔术师”时应该对客户的零件应用折扣会怎么样？
6. 当部件的成本超过院长经理向客户引用的价格时会发生什么？
7. 谁验证部分是否正确向船上拥有的船只收费？
8. 在工做在船上开始以前是否老是建立工单，仍是有例外？

这些只是从考虑各类问题产生的一些问题。它不能夸张，所以我将再次说明：从验证，纠错和异常处理的角度来看，须要考虑全部问题。这些不是编程问题。这些是过程问题：现有业务流程如何处理这些状况？可是，他们将始终在现有过程当中揭示重大问题，影响实施决策，并致使您对项目原始估计的时间和成本超支。经过使用AOSD来识别问题，而后应用这些基本规则，您能够在不设计单个组件或编写一行代码的状况下，发现大量的系统。

为了乐趣，我将根据造船厂到达现场时如何操做来回答这些问题。

1. 院长经理如何根据物料要求验证客户是否正确计费？

   经过审查每一个账单。若是院长经理记得特殊的命令，那就有机会犯错误。

2. 谁验证库存是否正确从库存中扣除？

   没有人。不执行标准库存准确机制，如循环计数。

3. 谁验证零件，特殊订单是否正确添加到工单？

   院长经理对于工做须要的部分有“感受”。

4. 谁负责肯定零售价格并采起折扣？

   基本上没有人 本质上，采购部门根据制造商的建议零售价格（MSRP）设订价格，但零件一般没有MSRP，所以是至关随意的。

5. 当院长经理忘记通知这个“魔术师”时应该对客户的零件应用折扣会怎么样？

   会计部门必须对帐单进行手动修改。若是账单没有及时收到，则会发出贷项凭证，下次在客户的账单上显示。

6. 当部件的成本超过院长经理向客户引用的价格时会发生什么？

   没有。该公司吃亏。此外，亏损不会转交给会计师，因此它永远不会显示为损失。

7. 谁验证部分是否正确向船上拥有的船只收费？

   没有人。没有计算对船厂拥有船只的部分。会计师估计每个月结算。

8. 在工做在船上开始以前，老是建立工单，仍是有例外。

   不，常常在忙碌的时候，会发出一个口头的工单。

   看起来能够是欺骗性的，但区别是清楚的⁴

获得教训

当我开始研究院子的过程和自动化时，不采用AOSD技术，由于我不明白问题的深度，因此我花了大约三到四个月的时间完成了错误的方向。讽刺的是，我已经作过几年的过程自动化，我应该更好地知道。但外表多是欺骗。这个特殊的船厂从外面看起来很是好（这正是他们但愿客户如何看待它们），但在内部，事情正在发生。由于他没有收到六个月前购买的6,000美圆的小费（这其实是这样），因此打电话的客户可能更好地了解了内部问题。

工件（对象和组件）

如今，我将采起大胆的步骤，从关注自己而不是任何正式的要求文件中肯定一组基本的组件。这使咱们摆脱了抽象的关注问题，并使咱们回到更具体的设计和实施问题。能够经过通常性声明的语义和关注点来识别如下组件：

• 工单
• 物料要求
• 客户账号
• 库存
• 发票（帐单）
• 部分
• 折扣

这些彷佛是合理的组件，而无论实现细节和区域设置（例如，在内存对象，XML数据，数据库表等中）。根据要求，这些组件可能以全部这些形式和其余形式存在。

锅炉问题

在这一点上执行的一个有趣的步骤是考虑这些工件的问题。工件的锅炉问题包括如下问题：

• 对象/信息建立日期/时间
• 关闭日期/时间
• 活动，不活动或已删除
• 更新/更改历史记录
• 错误检查
• 异常处理
• 信息的完整性
• 伐木

请注意，这些关注能够在组件中内部处理，而且在大多数状况下不须要与其余组件交互。例外状况是最后三个项目，异常处理，信息完整性（生成问题警报）和日志记录，可能涉及其余“帮助”组件。这些只是组件可能拥有的一些常见问题，不管要求如何。在应用程序的复杂性增长和添加新功能后，设计具备这些问题的组件可能会很是有用。除了这些样板问题外，还能够从需求文件和产品开发过程当中肯定具体的应用问题。

在提供给客户的实际系统中，只解决了其中一些问题。在这一点上我感到遗憾的是，诸如变革历史等关切并非原来实施的一部分。然而，因为实现与横切问题（使用应用自动化层框架！）有很好的关系，因此其余问题的实现很是简单，不会破坏现有的系统。

横切

采起单一过程，肯定零件的价格，说明了实施的横切（在这种状况下，上述组件）。即便在这个早期的设计阶段，没有进入每一个组件的实现细节，能够证实，肯定零件的价格应该出如今客户的账单上，这涉及系统的许多不一样组件。下图说明了使用“后箱”的概念来肯定价格。

不幸的是，AOSD并无提供任何关于如何处理这个横切的指导方针，而不是帮助肯定其存在。“编织”的概念将在下面的AspectJ部分中进行讨论，这是试图提供形式主义（语言实现）来解决横切问题。

看点小号

在上述示例中，价格计算是一个方面，由于它迫使组件实现的横切。我认为正确的用法是“价格计算方面”。

像许多最近的范例旨在解决复杂软件开发中出现的一些问题，AOSD在实际实现的流出中包含了智慧的宝石³

AspectJ

让读者注意我不是Java程序员，若是我有任何话，我但愿永远不会。所以，本节将至关简短。若是您想了解此语言扩展的完整语法，您能够参考如下参考部分。也就是说，在这个语言扩展中有一些有趣的（也许更合适的术语应该是“奇怪”）的功能，值得阅读。为了演示实现，须要定义一些额外的术语，在这些定义中，您将找到示例用法和进一步的讨论。

加入点

链接点是程序执行中“明肯定义”的任何一点。从高级语言的角度来看，这将是调用方法，访问数据，存储值，对象建立和破坏（垃圾回收语言除外），异常处理程序等的地方。这基本上排除了算术和布尔运算（除非重载或处理setter / getter字段），而从低级汇编语言的角度来讲，执行高级指令所必需的中间机器指令。

讨论

您可能认为C＃的“set”和“get”语言结构抽象了属性的链接点的概念，或者C＃和C ++的继承和重载特征抽象了方法和操做符的链接点的概念。不是这种状况。链接点中涉及到的问题确实要求语言直接支持“一流公民”，而不是使用现有的面向对象技术。这主要是因为能够拦截链接点的丰富程度以及在现有语言结构中模拟此概念所需的体力劳动（参见下面的“切入点”）。

切入点

切入点（或切入点指示符）是在程序中选择链接点的规范。给定一个链接点（程序执行中你感兴趣的地方），切入点是用于使用正式语法向链接点传达对编译器或解释器的兴趣的语法和机制。不幸的是，你会看到诸如“到达切入点时运行的代码”这样的句子，这是至少使人困惑的。当程序执行到达链接点时，切入点向量程序执行到“通知”（见下文）。这种术语混淆使得很难理解，并且还要购买AspectJ中提出的语言扩展。

用法

给定一个对象Point，指定截取对象Point的更改的切入点将以下[6]：

pointcut fieldChanged(Point changed) : 
call( * Point.set*(..)) && target(changed);

讨论

这种语言扩展的一个有趣（奇异的）功能之一是使用通配符。您能够经过指定“call（*。*（..））”做为切入点，在全部函数调用上建立切入点。您能够经过指定“call（Point。*（..））”做为切入点，为类中的全部方法指定切入点。另外一个控制领域是指定呼叫源的能力。若是您有两个类（Line和Rectangle），则此功能容许您区分并指定不一样的切入点，当“线”操做点与“矩形”操做点时的操做。这些能够嵌套到任何级别。还有另外的结构提供了更多的复杂性，例如“内部”，“内部代码”，“cflow”和“cflowbelow”，这里再也不赘述。

忠告

建议是当达到切入点指定的链接点时执行的代码。在建议中，您能够指定要在截取（或剪切）的代码以前，以后和/或以后运行的代码（“围绕”）。经过这种机制，建议或加强功能被“编织”到现有的实施中。

用法[6]：

after(Point changed ) : fieldChanged(changed)
         {
         changed.makeDirty();
         }

讨论

从汇编语言程序设计的日子开始，这听起来只不过是一个荣耀的“补丁”。此外，切入点规范与架构实现，程序流程和类实现密切相关。这致使更多的反作用，而不是更少，当实施变化。此外，这种实现使测试复杂化，由于它扩展了能够达到代码的路径数量以及决定代码执行的决策。虽然这种语言扩展提供了一些有趣的思想食物，但我根本不能相信它能够被认为是AOSD肯定的横切问题的解决方案。AspectJ的支持者将认为它容许轻松添加记录和安全检查等功能。这些是经过现有机制（如重构）处理得更好的简单示例，坦率地说，经过更好的前端设计。使用这种语言扩展，应用程序将迅速演变成一个拼凑的切入点规范，将代码的可读性下降到零，由于代码的相干结构具备编织的拼接。此外，这种语言扩展彷佛不适合复杂（我敢说“真实世界”）的例子，例如上面讨论的案例研究。

实质上，AOP是一种编程技术¹

结论

显然，AOSD不是软件生产中涉及到的问题的完美解决方案，但若是您尚未本身制定，这是一个很好的起点。有了经验，您应该能够调整AOSD的概念，以更好地适应本身的工做环境，客户群体，团队成员等。AOSD解决方案主流语言中几乎没有语言支持。就我的而言，我认为语言扩展是彻底错误的方向。若是有的话，他们会战胜AOSD的目的，由于至少在AspectJ的时候，组件之间的联系彷佛更为紧密。此外，程序流程的单独规定仅仅增长了程序员的混淆，而且须要跟踪单独但相关的实现细节。代替，经过设计适当的框架来管理横切，AOSD提出的问题能够在现有工具（如设计模式）和语言（如C＃，C ++）中获得更好的解决。这个做者（AAL的另外一个插件）的一个这样的解决方案经过消除没必要要的对象结构，将数据视为一个单独的事件能力的实体来实现这一点，而且经过脚本语言提供工做流机制以将自主组件粘合在一块儿以实现所需的过程。

参考文献

因为这不是一份正式的论文（并且由于我太懒了），我没有在文章自己中提到任何脚注，当我作出某些陈述时，我提到的其余做者。我能够听到大学警察如今在敲门。不管如何，全部这些均可以在互联网上找到（一些经过ACM，一个优秀的在线编程技术来源），在大多数状况下，AOP，AOSD和AspectJ的信息来源不少。若是你本身阅读，你能够弄清楚我是改写什么，哪里。对于那些可能冒犯的做者，请注意，除非另有说明，不然本文中没有我直接引用你的内容。我更喜欢改写和重写，以便通常的编程社区有一些机会理解你的“

• Elrad，Filman和Bader，2001年10月/ Vol。44，第10号交流通信

• AOSD，AOSD 2002--1st International Conference Aspect-Oriented Software Development，http://trese.cs.utwente.nl/aosd2002/

• 马克·克利夫顿

• 彼得·加布里埃尔

• Stojanovic和Dahanayake。组件和观点做为系统设计中的综合分离关注
• 巴特宁和奥尼尔。在超级空间中的意想不到的构成

• Chitchyan，Sommerville和Rashid。横切关注的设计方法分析

• Graversen和Beyer。使用角色的概念编程

• 萨顿和塔尔。面向方面的设计须要关注建模

• Wagelaar和Bergmans。使用基于概念的方法面向方面的软件设计

• Akkawi，Bader和Elrad。动态编织建筑可重构软件系统

• 塔克和克里斯哈尔西 高级语言中的切入点和建议
• 汉曼和凯撒雷斯。Java和AspectJ中的设计模式实现
• 克拉克和沃克。达到AOSD的标准设计语言