AOP软件设计

什么是面向方面的编程？
为什么面向方面的软件设计？
术语
关注
视口
关注点分离
人工制品
横切
方面
编织
零件
形式主义

第二节

案例研究
关注
人工制品
横切
方面
AspectJ
加入点
切入点
忠告
结论
参考文献

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

什么是面向方面的编程？

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

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

为什么面向方面的软件设计？

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

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

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

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

术语

到目前为止，我已经避免使用与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控件有关。为了本文的目的，术语组件被定义为“...封装的自治服务提供者，通过良好指定的接口提供有用的服务，使其存在于更广泛的上下文中，并与其他组件协作实现共同目标。 “ 5考虑这个定义，即“...并与其他组件合作”，这意味着在其实现中的横切。嗯

形式主义

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

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

案例研究

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

关注

一，关于处理零件的一般性陈述。请记住，当我开始看自动化操作时，没有一个以任何一致的方式写下来。这是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. 在工作在船上开始之前，总是创建工单，还是有例外。

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

    看起来可以是欺骗性的，但区别是清楚的4

得到教训

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

工件（对象和组件）

现在，我将采取大胆的步骤，从关注本身而不是任何正式的要求文件中确定一组基本的组件。这使我们摆脱了抽象的关注问题，并使我们回到更具体的设计和实施问题。可以通过一般性声明的语义和关注点来识别以下组件：

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

这些似乎是合理的组件，而不管实现细节和区域设置（例如，在内存对象，XML数据，数据库表等中）。根据要求，这些组件可能以所有这些形式和其他形式存在。

锅炉问题

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

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

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

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

横切

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

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

看点小号

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

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

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是一种编程技术1

结论

显然，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的标准设计语言
posted @ 2017-05-03 12:39  最后一个BUG  阅读(583)  评论(0)  编辑  收藏  举报