面向对象的方面 vs. 面向类的方面

很明显，方面解决的是系统（非功能性）需求，而类解决的是业务（功能性）需求。系统需求是在软件执行时的运行时需求，最好在对象级别解决。

不幸的是，多年来，大多数 AOP 产品/工具都试图在设计时在类级别解决方面问题。这也许可以解释为什么 AOP 至今仍未被广泛采用。我认为，类应该只关注业务需求。它们不应该关注系统需求。系统需求应该在类对象被使用时，在对象级别解决。

原因如下。类只是一个对象集合的模板。在设计类时，你通常不知道（或者可能永远不会知道）它的对象在每种情况下的使用方式。以日志记录（顺便说一下，这是一个系统需求）为例。如果你将进入/退出日志记录方面添加到 employee 类的某个方法中，从该类创建的每个对象在执行该方法时都会输出进入/退出日志。如果你的代码只是循环遍历几个 employees，这可能没问题。但是，如果你有成千上万的 employees，你真的想记录循环中的每次进入/退出吗？你无法预料到这种情况。

我的观点是：在设计类时，决定是否需要将方面应用于该类还为时过早。那么，考虑方面的时间是什么时候呢？答案是在你使用类的对象时。当你使用类的对象在代码中时，你了解对象被使用的确切情况。然后，你可以决定是否需要为该对象添加方面。如果是，可以使用 动态装饰器（或者其他工具）在适当的位置将方面附加到对象上。

使用 动态装饰器，可以分别解决业务需求和系统需求。你使用 OOP 设计类来满足业务需求。然后，你使用 动态装饰器 根据系统的运行时需求，根据需要将方面附加到对象上。

我同意 Dino Esposito 在他的文章 面向方面编程、拦截和 Unity 2.0 中评论道，AOP 采用受限的主要原因是缺乏合适的工具。更具体地说，我想说的是，虽然存在许多 AOP 工具，但仍然缺乏在正确的时间和正确的地点解决方面的工具。

动态装饰器 可能是第一个认真在对象级别解决方面的工具之一。我预见未来会有更多的工具出现，以对象级别解决方面问题，原因有两个。首先，需求是存在的。其次，一旦人们意识到方面属于运行时的对象而不是设计时的类，他们可能会将重点转移到解决对象级别的 AOP 问题上。

有关面向对象的更多信息，请参阅文章 使用动态装饰器添加对象方面。