Design patterns 交叉关注点示例

横切关注点的好例子是什么？页面上的病历示例对我来说似乎不完整

特别是从这个例子来看，为什么日志记录会导致代码重复（分散）？（除了像
log（“..”）
everywhere这样的简单调用之外，这似乎没什么大不了的）

核心关注点
和横切关注点

之间有什么区别

---

我的最终目标是更好地理解AOP

我认为交叉关注的最好例子是交易行为。例如，必须在所有服务方法中使用提交和回滚调用放置try-catch块，这将是一种排斥。用一个标记来注释这些方法，AOP可以用它来封装这些方法，从而实现所需的事务行为，这是一个巨大的成功

另一个很好的交叉关注点示例是授权。与在服务方法代码中处理该方法相比，使用一个标记来注释一个服务方法，告诉谁可以调用它，并让一些AOP建议决定是否允许该方法调用可能更可取

使用AOP建议实现日志记录可能是获得更大灵活性的一种方法，这样您就可以通过更改连接点来更改记录的内容。在实践中，我并不经常看到这样的项目。通常，如果需要的话，在运行时使用log4j这样的库可以让您通过记录级别和类别进行过滤，效果很好

---

一个核心问题是应用程序存在的原因，即应用程序自动化的业务逻辑。如果您有一个处理货运的物流应用程序，那么计算出您可以在卡车上装载多少货物，或者卡车运送货物的最佳路线可能是核心问题。交叉关注点通常是需要与业务逻辑分开的实现细节。

除了公认的答案之外，我还想提到另一个交叉关注点示例：远程处理。假设我只想在本地调用生态系统中的其他组件，就好像它们在进程中运行一样。也许在某些情况下，他们甚至会这样做。但现在我想在云或集群中运行我的分布式服务。作为一名应用程序开发人员，我为什么要关心这方面？一个方面可以负责找出呼叫谁以及如何呼叫，必要时序列化传输的数据并进行远程呼叫。如果一切都在进程中运行，则方面只会转发本地调用。在被调用方端，方面将反序列化数据，进行本地调用并返回结果

现在，让我告诉您一个关于日志输出之类的“琐碎”事情的小故事：就在几周前，我为客户机重构了一个复杂但不太大的代码库（大约25万行代码）。在几百个类中使用了一种日志框架，在另外几百个类中使用了另一种日志框架。然后有几千行的

System.out.println（*）

实际上应该有日志输出。因此，我最终修复了分散在整个代码库中的数千行代码。幸运的是，我可以在IntelliJ IDEA（结构化搜索和替换）中使用一些聪明的技巧来加快整个动作，但是，孩子，你不认为这是微不足道的！当然，强烈依赖于上下文的调试日志记录总是发生在方法体中，但许多重要的日志记录类型，如跟踪方法调用（即使是按层次结构，输出缩进很好）、记录已处理或未处理的异常、用户审核（根据用户角色记录对受限方法的调用）等等可以很容易地在方面实现，而不会污染源代码。日常应用程序开发人员不需要考虑它，甚至不需要看到分散在代码库中的记录器调用。有人负责使方面保持最新，甚至可以在一个地方集中切换日志策略或整个日志框架

---

我可以为其他交叉关注点提出类似的解释。保持代码干净、不受IMO的分散和纠缠是一个专业性的问题，而不是任何可选的问题。最后但并非最不重要的一点是，它保持了代码的可读性、可维护性和可重构性。阿门。

在理解横切关注点之前，我们必须理解关注点

问题是指根据功能划分的系统部分

有两种类型的担忧：

表示主要需求的单一和特定功能的关注点称为核心关注点 或
系统的主要功能称为核心关注点。
例如：业务逻辑

表示二级需求功能的关注点称为横切关注点或系统范围关注点 或
横切关注点适用于整个应用程序，并影响整个应用程序。
例如：日志记录、安全性和数据传输是应用程序几乎每个模块都需要考虑的问题，因此它们是交叉关注点

此图表示分解为模块的典型应用程序。每个模块的主要关注点是为其特定领域提供服务。但是，这些模块中的每一个都需要类似的辅助功能，例如安全日志记录和事务管理。横切关注点的一个例子是“日志记录”，它经常在分布式应用程序中使用，通过跟踪方法调用来帮助调试。假设我们在每个函数体的开头和结尾都进行日志记录。这将导致横切至少有一个函数的所有类

交叉铜