「合 vs. 分」也適用於方法層級。
別只看長度#
「方法超過 N 行就拆」這種教條基本上沒道理。
- 拆方法引入新介面 → 增加複雜度
- 把原本相關的程式碼分散開 → 反而更難讀
- 只在能讓系統整體更簡單時才拆
長方法不一定是壞事。深方法（功能多、介面簡單）即使有上百行也沒問題。
Figure 9.3: 方法 (a) 可透過抽出子任務 (b) 或拆成兩個獨立方法 (c) 來分割；若拆完反而變成淺方法 (d)，就不該拆
兩種良性的拆法#
拆法 A：抽出子任務（Extract subtask）#
把一段子任務抽成獨立的子方法，父方法呼叫它：
- 父方法的介面保持不變
- 適用條件：子任務能乾淨地獨立
- 讀子方法的人不需要懂父方法
- 讀父方法的人不需要懂子方法的實作
通常子方法會偏通用——可被父方法以外的方法重用。
紅旗：連體方法（Conjoined Methods）#
拆完之後若你發現自己得在父子方法之間來回翻才能搞懂如何運作 → 拆錯了。
兩段程式碼物理上分開，但只有看著彼此才能理解 → 紅旗。
拆法 B：拆成兩個對外可見的方法（Split into two methods）#
當原方法介面本身過於複雜（同時做好幾件不密切相關的事），把它拆成兩個或多個各自承擔一部分功能的較小方法：
- 每個新方法的介面都應比原方法的介面簡單
- 理想狀態：多數呼叫端只需要呼叫其中一個
若呼叫端必須呼叫所有新方法、在它們之間搬狀態 → 拆得不好（很容易演化成多個淺方法）。
此類拆分應以「呼叫端是否變得更簡單」為判準。
反過來：合併方法#
有時把方法合在一起反而讓系統更簡單，例如：
- 用一個更深的方法取代兩個淺方法
- 消除重複
- 消除原本兩個方法間的依賴或中介資料結構
- 讓原本散落多處的知識集中封裝
- 簡化介面（呼應 9.2 節）
結語#
設計方法時的最重要目標：乾淨、簡單的抽象。
- 每個方法應做一件事且做完整
- 介面要乾淨簡單，呼叫端不必背負大量資訊
- 方法應該是深的：介面比實作簡單得多
滿足這些條件的方法，長或短都不重要。