橫切關注示例

Question

cross-cutting concern的一個很好的示例是什麼？ wikipedia頁面上的醫療記錄示例對我來說似乎不完整。

特別是從這個例子中，爲什麼日誌會導致代碼重複（scattering）？ （除了簡單的電話，如log("....")無處不在，這似乎不是什麼大不了的事）。

core concern和cross-cutting concern有什麼區別？

我的最終目標是更好地理解AOP。

Answer 1

在瞭解橫切關注點之前，我們必須瞭解關注點。

甲關注是指系統的功能的基礎上劃分的一部分的術語。

關注是兩種類型：表示用於爲芯涉及主要要求是公知的單和特定功能

1. 的擔憂。
   或
   該系統的主要功能被認爲是核心問題。
   例如：商業邏輯
2. 表示用於次級需求功能的關注被稱爲橫切關注點或全系統的擔憂。
   或
   橫切關注點是一個在整個應用程序中都適用的問題，它影響整個應用程序。
   例如：日誌，安全和數據傳輸是應用程序幾乎每個模塊都需要考慮的問題，因此它們是交叉問題。

Courtesy

該圖表示一個典型的應用程序，它被分解成模塊。每個模塊的主要關注點是爲其特定的域提供服務。但是，這些模塊中的每一個還需要類似的輔助功能，例如安全日誌記錄和事務管理。橫切關注的一個例子是「日誌記錄」，這在分佈式應用程序中經常使用，通過跟蹤方法調用來幫助調試。假設我們在每個函數體的開始和結束都進行日誌記錄。這將導致橫切所有至少有一個函數的類。

(Courtesy)

Answer 2

我認爲跨領域問題的唯一最好的例子就是交易行爲。例如，必須在所有服務方法中使用提交和回滾調用來放置try-catch塊。用AOP可用來將它們與期望的交易行爲封裝在一起的標記來註釋這些方法是一個巨大的勝利。

作爲跨領域關注的一個例子，另一個很好的候選人是授權。使用標記來註釋服務方法，告訴誰可以調用它，並讓一些AOP建議決定是否允許方法調用，這比在服務方法代碼中處理更好。

使用AOP建議實現日誌記錄可能是獲得更多靈活性的一種方式，因此您可以通過更改連接點來更改記錄的內容。在實踐中，我看不到經常這樣做的項目。通常使用像log4j這樣的庫，可以根據日誌級別和類別進行過濾，如果需要，可以在運行時進行篩選，工作得很好。

核心問題是應用程序存在的原因，即應用程序自動化的業務邏輯。如果您有一個處理運輸貨物的物流應用程序，計算出您可以在卡車上裝多少貨物，或者卡車採取什麼樣的最佳路線來卸貨，可能會成爲核心問題。橫切關注點通常是需要與業務邏輯分開的實現細節。

Answer 3

除了我接受的答案之外，我想提出另一個橫切關注的例子：遠程處理。假設我只想在本地生態系統中調用其他組件，就好像它們正在運行一樣。也許在某些情況下他們甚至可以。但是現在我想運行分佈在雲或羣集中的服務。爲什麼我應該關心這方面的應用程序開發人員？一個方面可以考慮找出誰打電話以及如何在必要時串行傳輸的數據並進行遠程呼叫。如果一切正在運行，該方面只會轉發本地通話。在被調用端，該方面會對數據進行反序列化，進行本地調用並返回結果。

現在讓我告訴你一些關於日誌輸出等「微不足道」事情的小故事：幾周前，我爲客戶重構了一個複雜但不是太大的代碼庫（大約250K行代碼）。在幾百個班級中，使用了一種記錄框架，另外還有另外幾百個記錄框架。然後有幾千行System.out.println(*)其中應該有日誌輸出。所以我最終修復了遍佈整個代碼庫的數千行代碼。幸運的是，我可以在IntelliJ IDEA中使用一些聰明的技巧（結構搜索&替換）以加速整個動作，但男孩不認爲這是微不足道的！當然，強烈依賴於上下文的調試日誌記錄將始終發生在方法體內，但許多重要的日誌記錄類型（例如跟蹤方法調用（甚至具有良好縮進輸出的分層結構）），記錄處理或未處理的異常，用戶審計基於用戶角色的受限方法）等等，可以很容易地在不污染源代碼的情況下實現。日常應用程序開發人員不需要考慮它，甚至不需要看到分散在代碼庫中的記錄器調用。有人負責保持方面是最新的，甚至可以在一個地方集中切換日誌記錄策略或整個日誌記錄框架。

我可以爲其他交叉問題提出類似的解釋。保持代碼清潔，避免散佈和糾纏IMO是一個專業性問題，而不是任何可選的。最後但並非最不重要的是，它使代碼可讀，可維護，可重構。阿門。