我浏览了在线文档，阅读了 wiki 条目、帖子和博客，但我仍然感到困惑。
- 简而言之，什么是面向方面编程？
- 它比面向对象编程更好吗？我应该忘记 OOP 吗？
- 如果没有，我怎么知道何时使用其中之一？两者之间的主要区别是什么？
- 我可以将其中一个重构为另一个吗？
我一直是一个面向对象的人，我想知道我是否需要犯叛国罪。
说真的，我很快就要开始一个新项目，我想在一开始就做出正确的选择。
I have skimmed the online documentation, read the wiki entry, the posts and the blogs, but I'm still puzzled.
- What is, in a nutshell, Aspect Oriented Programming ?
- Is it simply better then Object Oriented Programming ? Should I unlearn OOP ?
- If not, how do I know when to use one or the other ? What are the main differences between the two ?
- Can I refact one into the other ?
I have always been an OO man and I want to know if I need to commit treason.
Seriously, I'm starting a new project soon and I want to make the right choices at the beginning.
发布评论
评论（5）
简而言之，什么是面向方面编程？
简而言之，AOP 是不引人注意地将操作注入到另一个程序的典型流程中的能力。它可以让您捕获类实例化、方法调用、赋值等。
它比面向对象编程更好吗？我应该忘记 OOP 吗？
不，不。它可以与任何支持它的编程环境一起工作。 （见上文）。
如果没有，我怎么知道何时使用其中之一？两者之间的主要区别是什么？
通常，当您想要对数百个类实现某种操作而不操作类本身时，您可以使用 AOP。典型的例子是安全性（授权调用给定方法/类的权利）或日志记录。但根据我的经验，我不会用它来实现这个目的。 （老实说，我根本不使用它）。
如上所述，主要区别实际上并不存在，因为它们不具有可比性。但是，假设您想“正常”实现日志记录，只需在适当的点调用记录器即可：
但是使用 AOP，您可以创建一个附加到每个方法调用的“方面”，并记录“调用的方法 b”。关键是，在 AOP 中，您的方法更像是“霰弹枪”：您附加到所有内容，或者只是一小部分。手动添加日志记录通常更好。
我可以将其中一个重新转换为另一个吗？
不太相关，请参阅其他答案。再次考虑到安全性，您可以将典型的 OOP 模型 this.IsAllowed() 切换到 AOP 模型，例如 if(callingMethod.HasAttribute(foo)){ allowed = true;希望
这些答案有用。如果您希望我进一步扩展，请告诉我。
What is, in a nutshell, Aspect Oriented Programming ?
In a nutshell, AOP is the ability to inject actions into the typical flow of another program, unobtrusively. It lets you capture class instantiations, method calls, assignments, etc.
Is it simply better then Object Oriented Programming ? Should I unlearn OOP ?
No, and no. It works together with any programming environment that supports it. (See above).
If not, how do I know when to use one or the other ? What are the main differences between the two ?
You use AOP, generally, when you want to implement some sort of actions on hundreds of classes, without manipulating the classes themselves. Typical examples are security (authorisation of the right to call the given method/class) or logging. In my experience, though, I don't use it for this. (I don't use it at all, honestly).
As above, the main difference doesn't really exist, as they aren't comparable. But, say you want to implement logging "normally", you just call the logger at appropriate points:
But with AOP, you may create an 'aspect' that attaches to each method call, and log 'Method b called'. The point is that in AOP you approach is more 'shotgun': you attach to everything, or just a small subset. Manually adding logging is generally better.
Can I refact one into the other ?
Not really relevant, see other answers. Again with security, you could swap to an AOP model from a typical OOP model this.IsAllowed() to something like if(callingMethod.HasAttribute(foo)){ allowed = true; }
Hope those answers are useful. Let me know if you want me to expand further.
不，AOP 补充了 OOP，而不是取代它。 AOP 和 OOP 提供了不同类型的“粘合剂”来帮助您组合行为。当然，OOP 允许您通过继承和组合等方式组合行为。另一方面，AOP 允许您添加行为来解决 横切关注点，通过拦截新代码所在的切点在所选类的所选方法之前或之后运行。
横切关注点的一些常见示例是：安全性、日志记录和事务控制。良好设计的基本原则是连贯性：理想情况下，一段代码应该只做一件事。例如，向数据访问类添加安全代码会造成混乱。 AOP 通过让您在“方面”中添加行为，然后将该方面应用到所有应该具有安全控制的类来解决该特定问题。
No, AOP complements OOP, rather than supplanting it. AOP and OOP provide different kinds of "glue" to help you combine behaviors. OOP, of course, lets you combine behavior through inheritance and composition, etc. AOP on the other hand lets you add behavior to address cross cutting concerns by intercepting point cuts where your new code runs before or after the chosen methods of the chosen classes.
Some common examples of cross cutting concerns are: security, logging, and transaction control. A bedrock principle of good design is coherence: ideally, a piece of code should do just one thing. So it muddies the water to add security code to data access classes, for example. AOP solves that particular problem by letting you add the behavior in an "Aspect" and then applying that aspect to all the classes that should have security controls.
AOP 与 OOP 不同，开发方法完全不同。
基本上，如果您有日志记录、身份验证问题、性能检查代码，那么在程序的各个部分、不同的类中，这些代码大致都是相同的。因此，您可以按照您的设想用 Java 编写应用程序，然后当您需要添加这些其他类型的代码（横切关注点）时，您只需将它们注入到程序中，以便可以编译它们，但是当你查看源代码，你只会看到你需要的业务逻辑。
至于何时使用 AOP 或 OOP，我建议您编写程序，让它工作，然后当您使其正常工作时，考虑删除实际上与该功能无关但用于其他目的的代码。例如，如果您需要在使用输入参数之前检查它们是否正确，则可以使用方面。如果您有类似的事件处理，例如数据访问层中引发的所有异常都会写入日志文件，则为此创建一个方面。
当您消除这些横切问题时，您的代码将会变得更小。
随着您获得更多经验，您将看到 AOP 的更多用途，但最初我建议编写它，然后使用 AOP 进行重构。
如果使用 Java，请使用 Eclipse 进行 AOP，因为 AJDT 插件对于查看要在何处添加方面非常有用。
AOP is different than OOP, completely different approaches to development.
Basically, if you have logging, authentication concerns, performance checking code, these will be the same, roughly, in various parts of the program, in different classes. So, you can write your application as you envision it, in Java, then when you need to add in these other types of code (crosscutting concerns) then you just inject them into the program, so that they can be compiled in, but when you look at the source code, you just see the business logic you need there.
As to when to use AOP or OOP, I would suggest you write the program, get it working, then when you have it functioning, look at removing code that doesn't actually have to do with the function, but serves some other purpose. For example, if you need to check that the input parameters are correct before using them, then use an aspect for that. If you have similar event handling, such as all exceptions thrown in the data access layer writes to a log file, then create an aspect for that.
As you remove these crosscutting concerns your code will get smaller.
As you get more experience you will see more uses for AOP, but initially I would suggest write it, then refactor using AOP.
Use Eclipse, if using Java, for AOP, as the AJDT plugin will be very useful to see where you are adding aspects.
面向方面编程是一个流行词，用于在调用和返回等关键点将操作（称为“建议”）插入到方法或函数中。我对 AOP 有一个大问题，因为它违反了语言中内置的所有抽象障碍。模块无法说“这是一个方面可以搞乱的内容，而这是一个方面不能搞乱的内容”。结果，您面临着违反内部不变量的风险，并且破坏了模块化推理的原则（您可以理解一个模块，而无需理解它导入的其他模块的接口之外的任何内容）。
几年前，Raymie Stata 写了一篇精彩的博士论文，内容是关于面向对象语言如何控制子类化并防止其违反关键不变量。 AOP的相应工作还没有写。
虽然与任何其他流行的想法一样，AOP 已经取得了一些惊人的成功（例如，将日志记录改进到设计时未考虑到日志记录的应用程序），但总的来说，我建议您将 AOP 的使用限制在非常简单的情况。或者更好的是，直接对面向方面的编程说不。
Aspect-Oriented Programming is a catchy buzzword for inserting actions (called "advice") into methods or functions at key points like calls and returns, among others. I have a big problem with AOP because it violates all the abstraction barriers built into the language. There's no way for a module to say "this is what an aspect can mess with and this is what an aspect can't mess with." As a result, you risk violating internal invariants, and you destroy the principle of modular reasoning (you can understand a module without having to understand anything but the interfaces of the other modules it imports).
Some years ago Raymie Stata wrote a brilliant doctoral dissertation about how object-oriented languages might control subclassing and prevent it from violating key invariants. The corresponding work for AOP has yet to be written.
While as with any other idea that gains currency, AOP has enjoyed a few spectacular successes (e.g., retrofitting logging to an application not designed with logging in mind), on the whole I would urge you to confine your use of AOP to very simple cases. Or better yet, just say no to aspect-oriented programming.
推荐阅读：Eclipse AspectJ：使用 AspectJ 和 Eclipse AspectJ 开发工具进行面向方面编程
Recommended Reading: Eclipse AspectJ: Aspect-Oriented Programming with AspectJ and the Eclipse AspectJ Development Tools