前文吃光光. 先简单回一下. 首先是为什麽需要对系统做 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)