前文吃光光. 先簡單回一下. 首先是為什麼需要對系統做 decomposition ? 因為人的腦力有限, 無法同時對付整個系統. (換句話說, 如果人的腦力是現在的好幾倍, 那 code 應該會火星化好幾倍吧 XD) 被 decompose 的系統就形成了很多 module, 這些 module 必須被一一設計, 實作和維護, 而最後這些 module 必需能合作無間地達成原系統所需功能. 要做到這件事, 各 module 間的關聯 (中文不知說啥好, 英文叫 coupling) 必需要減到最小, 不然會太複雜以致於無法組合 (composability) 但單一 module 內部又需要緊密合作, 不能有些本質上複雜的事根本作不出來, 而且不好重用 (reusability). 現在大家熟知的 OO, 跟之前只用 function 的語言就是為了盡量達到這些要求, 將概念上完整獨立但又不會太龐大的一組東西(呃, 該怎麼稱呼XD) 放在一起, (英文就叫 concern) 一來不用擔心與別組較不相關的概念會起衝突 (所以可以比較放心地任意組合) 然後也可以較完整地拿到另一個系統重用 (因為可以較隨意組合). 就算要改 code, programmer 也可以專心地改這一個 module 這就叫 separation of concerns (的一種, 還有其它各類的 separation of concenrs) 很不幸地, 有些 concern 是無法單用 function set 或 class set 集合起來的, 註定會散落在系統各處 (或說是各個 module 內), 這情形就叫 crosscutting concerns (也就是說, 不管怎麼設計, 都不可能能模組化) 這時會改 code 就很痛了, 東改一塊, 西改一塊, 散在幾處就要做一樣的動作幾次. 等下次要再改時, 要又全部找到再一個一個改, 數量一多又會有漏的 XD 為了解決 crosscutting concerns, 目前比較有名的是 feature-oriented programming 和 aspect-oriented programming. 前一個是把該次的 refinement 集中在一處, 稱為 feature (好像有點倒果為因, 其實是為了加 feature, 把需要的 refinement 集中在一起 @@) 後一個是用類似 pattern matching 的方式把這種 concern 抓出來, 集中起來叫 aspect. 至於細節, 我也還在學. 不過可以確定的是, FOP 和 AOP 還是有不足的地方, 以後一定會有什麼 XOP, YOP, ZOP 的東西跑出來, 直到人腦也沒辦法處理這些東西為止 XD --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 71.136.247.250 ※ 編輯: march20 來自: 71.136.247.250 (01/26 15:39) ※ 編輯: march20 來自: 71.136.247.250 (01/26 15:40) ※ 編輯: march20 來自: 71.136.247.250 (01/26 15:41) ※ 編輯: march20 來自: 71.136.247.250 (01/26 15:41) ※ 編輯: march20 來自: 71.136.247.250 (01/26 15:41) ※ 編輯: march20 來自: 71.136.247.250 (01/26 15:42) ※ 編輯: march20 來自: 71.136.247.250 (01/26 15:43) ※ 編輯: march20 來自: 71.136.247.250 (01/26 15:44) ※ 編輯: march20 來自: 71.136.247.250 (01/26 15:44)