218

像这里和全世界的大多数开发人员一样，多年来我一直在使用面向对象编程 (OOP) 技术开发软件系统。因此，当我读到面向方面编程 (AOP) 解决了许多传统 OOP 无法完全或直接解决的问题时，我停下来想，这是真的吗？

我已经阅读了很多信息，试图学习这种 AOP 范式的关键，并且我在同一个地方，所以，我想更好地了解它在现实世界应用程序开发中的好处。

有人有答案吗？

4

7 回答 7

351

为什么是“对”？这不是“对”。您可以将面向方面的编程与函数式编程结合使用，也可以与面向对象的编程结合使用。这不是“vs”，而是“面向方面的编程与面向对象的编程”。

对我来说，AOP 是某种“元编程”。AOP 所做的一切也可以通过添加更多代码来完成。AOP 只是节省了您编写此代码的时间。

维基百科有这种元编程的最佳示例之一。假设您有一个带有许多“set...()”方法的图形类。每次设置方法后，图形的数据都发生了变化，因此图形发生了变化，因此需要在屏幕上更新图形。假设要重新绘制图形，您必须调用“Display.update()”。经典的方法是通过添加更多代码来解决这个问题。在您编写的每个 set 方法的末尾

void set...(...) {
    :
    :
    Display.update();
}

如果你有 3 个设置方法，那不是问题。如果你有 200 个（假设的），那么到处添加它会变得非常痛苦。此外，每当您添加新的 set-method 时，您必须确保不要忘记将其添加到末尾，否则您只是创建了一个错误。

AOP 在不添加大量代码的情况下解决了这个问题，而是添加了一个方面：

after() : set() {
   Display.update();
}

就是这样！无需自己编写更新代码，您只需告诉系统在到达 set() 切入点后，它必须运行此代码，它将运行此代码。无需更新 200 个方法，无需确保您不会忘记在新的 set-method 上添加此代码。此外，您只需要一个切入点：

pointcut set() : execution(* set*(*) ) && this(MyGraphicsClass) && within(com.company.*);

这意味着什么？这意味着如果一个方法被命名为“set*”（* 表示任何名称可能在 set 之后跟随），无论该方法返回什么（第一个星号）或它采用什么参数（第三个星号），并且它是 MyGraphicsClass 的一个方法，并且这个class 是包“com.company.*”的一部分，那么这是一个 set() 切入点。我们的第一个代码说“在运行任何设置切入点的方法后，运行以下代码”。

看看 AOP 如何优雅地解决这里的问题？实际上这里描述的一切都可以在编译时完成。AOP 预处理器甚至可以在编译类本身之前修改您的源代码（例如，将 Display.update() 添加到每个设置切入点方法的末尾）。

然而，这个例子也显示了 AOP 的一大缺点。AOP 实际上正在做一些许多程序员认为是“反模式”的事情。确切的模式称为“远距离行动”。

远距离动作是一种反模式（一种公认的常见错误），其中程序的一个部分中的行为会根据程序另一部分中难以或不可能识别的操作而发生巨大变化。

作为一个项目的新手，我可能只是阅读任何设置方法的代码并认为它​​已损坏，因为它似乎没有更新显示。我看不到set-method 的代码，在它执行之后，其他一些代码将“神奇地”执行以更新显示。我认为这是一个严重的缺点！通过对方法进行更改，可能会引入奇怪的错误。进一步理解某些事情似乎可以正常工作但并不明显的代码流（正如我所说，它们只是神奇地工作......不知何故），真的很难。

更新

澄清一下：有些人可能会觉得我说 AOP 是不好的东西，不应该使用。这不是我要说的！AOP 实际上是一个很棒的功能。我只是说“小心使用”。如果您将普通代码和 AOP 混为一谈， AOP只会导致问题。在上面的示例中，我们具有更新图形对象的值并绘制更新后的对象的方面。这实际上是一个方面。将其中的一半编码为普通代码，将另一半编码为方面是增加问题的原因。

如果您将 AOP 用于完全不同的方面，例如用于日志记录，您将不会遇到反模式问题。在这种情况下，该项目的新手可能想知道“所有这些日志消息来自哪里？我在代码中没有看到任何日志输出”，但这不是一个大问题。他对程序逻辑所做的更改几乎不会破坏日志设施，对日志设施所做的更改也几乎不会破坏他的程序逻辑——这些方面是完全分开的。使用 AOP 进行日志记录的优势在于，您的程序代码可以完全专注于做它应该做的任何事情，并且您仍然可以拥有复杂的日志记录，而不会让您的代码到处被数百条日志消息弄得一团糟。此外，当引入新代码时，神奇的日志消息将在正确的时间以正确的内容出现。

因此，在我的示例中，AOP 的一个很好的用法是始终记录是否通过 set 方法更新了任何值。这不会产生反模式，也几乎不会成为任何问题的原因。

有人可能会说，如果你可以轻易地滥用 AOP 来制造这么多问题，那么将它全部使用是个坏主意。然而，哪些技术不能被滥用？你可以滥用数据封装，也可以滥用继承。几乎所有有用的编程技术都可能被滥用。考虑一种编程语言非常有限，它只包含不能被滥用的功能；一种语言，其中功能只能按照最初打算使用的方式使用。这种语言将非常有限，以至于它是否可以用于现实世界的编程也是有争议的。

于 2008-10-24T09:21:17.003 回答
35

面向方面的编程提供了一种很好的方式来实现横切关注点，如日志记录、安全性。这些横切关注点是必须在许多地方应用但实际上与业务逻辑没有任何关系的逻辑片段。

您不应该将 AOP 视为 OOP 的替代品，而应将其视为一个不错的附加组件，它使您的代码更加干净、松散耦合并专注于业务逻辑。

因此，通过应用 AOP，您将获得 2 个主要好处：

  1. 每个关注点的逻辑现在都在一个地方，而不是分散在整个代码库中。

  2. 类更简洁，因为它们只包含主要关注点（或核心功能）的代码，而次要关注点已移至方面。

于 2008-10-24T09:11:28.143 回答
29

OOP 和 AOP 不是相互排斥的。AOP 可以很好地补充 OOP。AOP 对于向方法添加标准代码（如日志记录、性能跟踪等）特别方便，而不会用此标准代码阻塞方法代码。

于 2008-10-24T09:09:24.170 回答
11

我认为这个问题没有一般性的答案，但需要注意的一点是，AOP 并没有取代OOP，而是添加了某些分解功能，以解决所谓的主导组合( 1 ) 的暴政（或横切关注点）。

只要您能够控制用于特定项目的工具和语言，它在某些情况下肯定会有所帮助，但也会增加有关方面交互的复杂性以及对AJDT等其他工具的需求仍然可以理解你的程序。

Gregor Kiczales 曾经在 Google Tech Talks 上发表过关于 AOP 的有趣介绍性演讲，我推荐观看：Aspect Oriented Programming: Radical Research in Modularity。

于 2008-10-24T09:16:29.197 回答
8

首先AOP不会取代OOP。AOP 扩展了 OOP。OOP 的思想和实践保持相关性。拥有一个好的对象设计可能会更容易用方面来扩展它。

我认为AOP带来的想法很重要。我们需要想办法在程序中的不同类上实现横切关注点，而不必更改类本身。但我认为 AOP 最终将成为我们使用的其他工具的一部分，而不是单独的工具或技术。我们已经看到这种情况正在发生。

像 Ruby 和 Python 这样的一些动态语言具有像 mixins 这样的语言结构来解决相同的问题。这看起来很像 AOP，但更好地集成在语言中。

Spring 和 Castle 以及其他一些依赖注入框架具有向它们注入的类添加行为的选项。这是一种运行时编织的方式，我认为这有很大的潜力。

我认为您不必学习一个全新的范例来使用 AOP。这些想法很有趣，但正在慢慢被现有工具和语言所吸收。随时了解并尝试这些工具。

于 2008-10-24T09:16:57.540 回答
7

OOP主要用于组织您的业务逻辑，而AOP 有助于组织您的非功能性事物，如审计、日志记录、事务管理、安全性等。

通过这种方式，您可以将业务逻辑与非功能性逻辑解耦，从而使代码更简洁。

另一个优点是您可以非常一致地应用建议（例如审计），而无需实现任何接口，这为修改提供了极大的灵活性，而无需触及业务逻辑。

这种方式很容易实现关注点分离和单一职责。

此外，当它只解决一个业务问题时，它很容易将业务逻辑从一个框架（比如 Spring）移植到其他地方（将来）

于 2019-06-28T14:57:11.827 回答
1

AOP 是处理这个概念的一种新的编程范式。一个方面是实现应用程序的特定非功能部分的软件实体。

我认为这篇文章是开始面向方面编程的好地方： http ://www.jaftalks.com/wp/index.php/introduction-to-aspect-oriented-programming/

于 2010-10-13T11:30:34.370 回答