時序分解（temporal decomposition）：系統結構對應到「操作發生的時間順序」。

這是常見的資訊洩漏成因。

經典範例#

考慮一個應用程式：

1. 讀某個格式的檔案
2. 修改檔案內容
3. 把修改後的檔案寫回去

時序分解傾向把它拆成三個類別：

• 一個負責讀檔
• 一個負責修改
• 一個負責寫檔

問題在於：讀檔與寫檔兩個類別都要懂這個檔案格式 → 資訊洩漏。

比較好的做法#

• 把「讀檔」與「寫檔」的核心機制合併到同一個類別
• 該類別在讀階段與寫階段都會被使用
• 檔案格式的知識集中在一個地方

為什麼容易掉進陷阱#

寫程式時，操作的執行順序常常是你腦中最強烈的線索——很自然就照那個順序拆模組。

但實際上：

• 多數設計決策會在應用生命週期中多次浮現
• 因此時序分解經常導致資訊洩漏

順序當然重要——但別讓它決定模組結構#

執行順序會被反映在程式裡的某個地方，這沒問題。但：

不要讓順序決定模組結構——除非該結構恰好與資訊隱藏相容（例如不同階段使用完全不同的知識）。

設計模組時，聚焦在「執行每項任務需要哪些知識」，而不是「任務的發生順序」。

紅旗：時序分解（Red Flag: Temporal Decomposition）#

在時序分解中，執行順序被反映在程式碼結構上：發生在不同時間的操作被放在不同的方法或類別。

如果同一份知識在不同時間點都會用到，就會被編碼在多處，造成資訊洩漏。