David Parnas 如何讓大型程式保持可變？資訊隱藏、模組化與責任邊界
Q：David Parnas 主要貢獻是什麼？ A：他是軟體工程先驅，以資訊隱藏、模組化設計、介面責任與大型系統維護研究聞名。
Q：資訊隱藏是什麼？ A：模組把可能改變的設計決策藏在內部，只透過穩定介面與其他模組互動，降低外部程式對內部細節的依賴。
Q：模組化如何降低變更成本？ A：當需求改變只影響一個模組，理解、測試、部署與回復的範圍就能被控制，不必整個系統一起重寫。
Q：責任邊界應如何設計？ A：應依設計決策、可能變動的原因與資料／流程責任切分，而不是只按組織部門、語言檔案或程式碼長度切割。
Q：介面需要說清楚什麼？ A：介面應定義輸入、輸出、錯誤、狀態、不變條件與相容性承諾，讓團隊能平行工作並替換實作。
Q：資訊隱藏和微服務一樣嗎？ A：不一樣。微服務是部署與網路架構；資訊隱藏是更一般的設計原則，可存在於單體、函式庫或分散式系統。
Q：如何檢查模組切得好不好？ A：觀察一項需求或設計決策改變時，影響是否集中、介面是否穩定、測試是否可定位，以及模組是否能獨立演進。
Q：模組化有什麼代價？ A：過度切分會增加介面、協調、序列化、網路與除錯成本；抽象只有在責任清楚且能隔離變動時才真正有價值。
Q：圖片與文章的關係是什麼？ A：圖片是 David Parnas、資訊隱藏、模組化、變更成本與軟體責任邊界的主題路線圖，不是某個實際程式庫的架構圖或部署監控畫面。
增量補充：資訊隱藏的驗收標準是變更隔離
IEEE Computer Society 的人物資料把 David Lorge Parnas 放在工業軟體開發與軟體工程研究的脈絡中。回到他的核心方法，資訊隱藏不是把程式碼藏起來，而是把容易改變的設計決策限制在責任清楚的模組內。來源：IEEE Computer Society — David Lorge Parnas。
最實際的驗收方式是做一次變更演練：替換資料格式、搜尋策略或外部服務，記錄需要修改的模組數、跨邊界的錯誤數與測試重跑範圍。如果一個小決策牽動大量呼叫者，問題通常不在團隊不夠努力，而在介面暴露了不該暴露的知識。這讓「模組化」從漂亮名詞變成可測量的變更風險。
先講結論
David Parnas 主張把可能變動的設計決策藏在介面後面，讓模組可獨立演進，降低大型軟體的變更成本。
David Parnas 是誰？
David Lorge Parnas 是加拿大軟體工程先驅，曾任 McMaster University 與 University of Limerick 榮譽教授。IEEE Computer Society 的人物資料把他的貢獻概括為以封裝與資訊隱藏讓大型系統更可管理，並把軟體開發建立在工程與數學的嚴謹性上。
資訊隱藏在隱藏什麼？
資訊隱藏不是把所有程式碼藏起來，也不是單純使用 private 欄位。它要求設計者先找出「未來可能變動、但其他模組不必知道」的決策，例如資料格式、裝置驅動、搜尋策略、排程規則或檔案配置，再讓模組只透過穩定介面提供行為。
這樣做的目的不是保密，而是限制變更的影響範圍。如果資料結構改變，外部模組只依賴介面，就不必同時修改；如果替換實作仍符合同一契約，團隊也能分開開發與測試。
1972 年論文改變了什麼？
Parnas 的〈On the Criteria to Be Used in Decomposing Systems into Modules〉發表於 1972 年《Communications of the ACM》。論文比較傳統的功能分解與以設計決策為中心的分解，指出後者在變更彈性與理解成本上可能更有優勢。
重要的是，Parnas 沒有提供一個永遠正確的模組清單。他把模組化視為設計判斷：哪些決策最可能改變？哪些知識應該只由一個模組負責？介面要暴露多少，才能讓其他團隊工作而不依賴內部細節？
模組化如何降低大型系統的變更成本？
1. 以變更風險，而非檔案大小切分
兩個小檔案不一定是兩個好模組；如果它們共同依賴同一個不穩定決策，變更仍會同時擴散。相反地，一個較大的模組只要把高風險決策集中管理，也可能更容易維護。
2. 把責任寫進介面與文件
介面應描述輸入、輸出、錯誤、前置條件與可觀察行為。Parnas 後續的文件工作也強調，文件不只是使用說明，而可以成為設計媒介：它把決策、開放問題與模組責任整理成團隊可以檢查的資料。
3. 讓替換成為可測試的假設
資訊隱藏的真正驗收方式，是能否以另一個實作替換原模組，而不讓呼叫者知道內部細節。如果替換必須修改大量外部程式，代表介面暴露了過多設計決策，或責任邊界沒有切好。
這和物件導向、微服務有什麼關係？
物件封裝、抽象資料型別、元件與微服務，都可以實現部分資訊隱藏，但它們不是同義詞。語言的 class 或服務的 HTTP endpoint 只是機制；是否真的降低耦合，要看介面是否穩定、資料責任是否清楚、錯誤是否可預期，以及團隊是否能獨立演進。
微服務尤其不能只靠拆服務數量判斷成功。若每個服務共享資料庫、跨服務呼叫密集，系統可能只是把耦合搬到網路上。Parnas 的問題仍然適用：哪個設計決策由誰負責？改變它時，影響範圍能否被控制？
常見問題
David Parnas 發明了資訊隱藏嗎？
他在 1972 年論文中系統化提出以設計決策為依據的模組分解與資訊隱藏原則，這是軟體工程史上的關鍵工作；但資訊隱藏後來由許多研究者、語言與工程實踐共同發展，不能簡化成單一語法或單一人的完整發明。
資訊隱藏和封裝一樣嗎？
不完全一樣。資訊隱藏是設計判斷：哪些決策不應被其他模組知道；封裝是語言或架構提供的實作機制。可以有封裝語法，卻仍暴露錯誤的責任邊界。
如何在專案中使用 Parnas 的方法？
列出可能變動的決策，將每項決策指派給一個模組，寫清楚介面契約，再用替換實作與變更影響測試驗證。若每次小改動都需要修改多個模組，回頭檢查分解是否按照錯誤的穩定性假設建立。
時間線
- 1960 年代：Parnas 開始發表大型系統與軟體工程相關研究。
- 1972：發表模組分解與資訊隱藏的經典論文。
- 1981：與合作者發展以文件作為軟體設計媒介的方法。
- 1999：持續倡議把軟體工程視為工程專業，而非只等同於寫程式。
- 2000 年代後：在 University of Limerick 推動軟體品質、文件與高可靠系統研究。
參考資料
- IEEE Computer Society：David Lorge Parnas profile
- ACM：On the criteria to be used in decomposing systems into modules
- McMaster Experts：Using Documentation as a Software Design Medium
- SEI：Software engineering for components
延伸閱讀
分享此文：
KEEP READING
接著讀什麼？
從同一主題繼續閱讀，或回到 YOLO LAB 的完整文章索引，找到下一個值得投入時間的問題。
發表迴響