三個基本應用模式

數億次的搜尋，世界有名氣的社群網站 Facebook、twitter、WhatsApp 等，每天都有數 億或數十億次的網際網路存取。若一百萬只出現１次的錯誤，在一千萬就變成 10 次，

這些案例模式有：一、Basic Retry；二、Parameterized Retry；三、Recovery From Multiple Exception；比較的重點放在程式碼糾纏程度與可讀性。

‧

案例模式一：Basic Retry 為了讓比較上可以方

Trace、Retry、WaitCorsor (管制 UI 以防呆)。在圖

‧

案例模式二：Parameterized Retry 第二案例也是把比較

的兩份程式碼擠到同一頁 以方便比較。在圖 4.3 中 的程式碼依然精簡且清 昕，或許會有像

RetryParam 這類不直覺 的指令出現，但只須一些 說明即可。RetryParam 的 功能是參數化重試，第一

圖 ４.3 Parameterized Retry with AspectW

圖 ４.４ Parameterized Retry without AOP mechanism

‧ 國

立 政 治 大 學

‧

N a tio na

l C h engchi U ni ve rs it y

案例模式三：Recovery From Multiple Exception

第三個案例算是比較符合真實的狀況，向遠端發出一個讀取數據的需求，這時可能 會有兩種故障是只要重試就行了。數據上的不一致錯誤（用 DataException）模擬，或 是網路的問題（用 IOException）模擬。這兩種故障用不一樣的應對方式。數據上不一 致的錯誤就要求遠端伺服器先刷新數據 (refresh data) 後再重新讀取數據。網路上的 錯誤就只能稍停一小段時間避開短暫的干擾或爆量延遲等狀況，然後再重新讀取數據。

有套用 AspectW 的程式碼就像圖 4.5 所示。若完全不導入 AOP 機制那就像圖 4.6 所示，

因為程式碼太長實在無法擠到同一頁所以分成兩段放在兩頁。

圖 ４.6 Recovery From Multiple Exception with AspectW - part1 圖 ４.5 Recovery From Multiple Exception with AspectW

‧ 國

立 政 治 大 學

‧

N a tio na

l C h engchi U ni ve rs it y

圖 ４.６ Recovery From Multiple Exception with AspectW - part2

在這三個案例裡，光是可以少寫很多程式碼就能達到相同邏輯這一點，就足以說服 我們自己了。仔細的觀看圖 4.2、圖 4.4、圖 4.6 就可以初步體會程式碼的糾纏(tangled) 狀態是什麼模樣。尤其是像重試(retry)這類在主功能邏輯程式碼區塊前面、後面與例

‧

接下來再引入二個文獻探討 CatchAndRetry[3]中提到的案例，這個案例來自 Facebook 系統，雖也只能模擬業務流程上相同需求邏輯，不過也更接近真實的應用狀 況，也是希望能以更接近真實的狀況下採用 AspectW。這兩個應用是：

一、Facebook Status Updates：取得使用者他所有朋友們最新的狀態並更新到自 已臉書的首頁。

二、Organizing a Facebook Event：發出一個邀請函給他住的城市或地區的朋友 們來參加一場派對。

第一個 Facebook 案例情境如圖 4.7 所示。有位名為“Alen”的人士他有四位好友。

此例只以四位好友為例，不過真實世界數百位才是常有的情境。他打算取出他所有好友 新更新的訊息。在執行中當然也要留下紀錄，事後可用來分析使用者行為。同時取得眾 多朋友的訊息過程中，若有一、兩位朋友的訊息取得失敗就忽略不管吧。