傳統的oop程式經常表現出一些不自然的現象，核心業務中總摻雜著一些不相關聯的特殊業務，如日誌記錄，許可權驗證，事務控制，效能檢測，錯誤資訊檢測等等，這些特殊業務可以說和核心業務沒有根本上的關聯而且核心業務也不關心。
這些特殊業務會帶來哪些問題呢？
1.**混亂，大量的外圍操作可能會混亂核心操作的**，而且當外圍模組有重大修改時也會影響到核心模組。
2.**分散和冗餘：同樣的功能**，在其他的模組幾乎隨處可見，導致**分散並且冗餘度高。
解決：假設現在我們把日誌、許可權、事務、效能監測等外圍業務看作單獨的關注點(也可以理解為單獨的模組)，每個關注點都可以在需要它們的時刻及時被運用而且無需提前整合到核心模組中。將每個關注點與核心業務模組分離，作為單獨的功能，橫切幾個核心業務模組。
aop使用場景介紹
一，效能統計／計數
說到＂優化＂，我們要做的第一件事是知道要優化什麼（定位系統瓶頸／優化點）～
比如，我們需要知道方法執行時間／呼叫次數等資訊～
常識告訴你，把這部分＂業務無關＂的邏輯寫入＂業務**＂是非常不合理的，你可能需要在每個需要＂監控＂方法前後埋點（方法執行前開啟計時器，離開方法後（前）停止計時器），在每個方法前乾一遍（哪怕只是簡單的呼叫兩個方法）是一件很蠢的事情；另外，可能系統執行一段時間後，你得到了需要的資料可能需要關閉這個功能（完美主義者可能無法容忍這種其實可以忽略不計的效能消耗），你需要自己實現乙個stopwatch，在邏輯中讀取乙個開關來確定是否關閉這個功能，要不然你就得改一遍所有的方法，把這部分**全部去掉～
更好方法就是aop攔截他們～你可能會考慮perf4j，使用註解的方式去攔截需要效能統計的方法～
也可以自己實現這種功能，通過全域性的配置在service/dao這種層級方法上面的***這個事情，等到你蒐集完需要的資料之後，你可以通過注釋掉配置關閉這個功能～
二，事務處理
用aop做事務處理的場景是最常見的，我們一般在＂事務方法＂前開啟乙個事務，離開方法後提交事務，方法丟擲異常時對事務進行回滾～其實其他資源的開啟和關閉的場景你也可以考慮這種方法；
三，快取處理
快取按照＂粒度／功能＂可以分為：頁面快取，方法快取／查詢快取，資料快取（對entity／資料記錄進行快取）等；
簡單的＂方法快取＂可以把＂方法名－引數＂作為key，***攔截方法根據＂方法名－引數＂去快取系統查詢，如果存在就直接返回，不需要執行方法真正的邏輯～
其他型別的快取思路其實也差不多～
四，協議轉換
五，日誌列印
除錯／開發的時候我為了方便會將dao層方法全部攔截，然後將返回資料列印出來（往往使用json或者在控制台列印乙個**）～
六，其他場景
資料加加密/簽名／驗簽名等場景；
支付行業往往對安全性要求比較高，我們在儲存／接收／傳送資料前先要對資料進行驗籤／簽名／加密等操作，甚至資料在儲存到資料庫的時候都需要做特殊處理，比如乙個手機號13812348888，我們需要在儲存前將它變成138[密文]8888這種形式，我們可以通過乙個＂***＂對手機號，身份證號這種敏感資訊做這種特殊處理；
如果你的介面需要對某些字段進行簽名，然後set到乙個指定的字段，這種時候aop也非常有用；
還有就是異常通知這種業務無關邏輯，你可以攔截一些要緊的方法，如果方法返回失敗或者丟擲異常，你可以非同步的呼叫乙個通知方法傳送乙個郵件或者簡訊什麼的，這樣你就能立即知道問題了（當然其實有更好的異常監控方法，我只是打個比方）～
Git使用場景 命令使用場景
通過個人使用git時候的遇到的使用場景，熟悉了解相關命令，也記錄一下場景的使用方法。所有場景均在ubuntu16.04 linux 作業系統下，其他作業系統有差異的地方自行查閱相關資料。安裝git sudo apt get install git設定及檢視git配置 user.name和user.e...
AOP這些應用場景 交叉業務
1.統計某個方法的效能，可以在每個業務方法執行前後 記錄方法執行的當前時間，執行後的時間 執行前的時間 方法執行時間。這樣就可以在開發過程中 專案未交付給客戶前 統計程式的效能。2.安全 許可權相關 3.資料庫事務 spring已經整合 4.日誌 呼叫 物件，由 物件呼叫目標物件，只是在呼叫前後加一...
AOP這些應用場景 交叉業務
1.統計某個方法的效能，可以在每個業務方法執行前後 記錄方法執行的當前時間，執行後的時間 執行前的時間 方法執行時間。這樣就可以在開發過程中 專案未交付給客戶前 統計程式的效能。2.安全 許可權相關 3.資料庫事務 spring已經整合 4.日誌 呼叫 物件，由 物件呼叫目標物件，只是在呼叫前後加一...