本章介紹了另一種思考如何創建更深層次類的方法。假設您正在開發一個新模塊，並且發現了一個不可避免的復雜性。哪個會更好呢：應該讓模塊的用戶處理復雜性，還是應該在模塊內部處理復雜性？ 如果復雜性與模塊提供的功能有關，那么第二個答案通常是正確的。大多數模塊的用戶都比開發人員多，所以開發人員比用戶遭罪更好。作為一個模塊開發人員，您應該努力使您模塊的使用用戶生活的盡可能輕松，即使這意味着您需要額外的工作。表達這一思想的另一種方式是， 對於模塊來說，擁有一個簡單的接口比簡單的實現更重要。
作為一名開發人員，很容易采取相反的方式：解決簡單的問題，把困難的問題推給其他人。 如果出現不確定如何處理的情況，最簡單的方法是拋出異常，讓調用者處理它。如果您不確定要實現什么策略，您可以定義一些配置參數來控制策略，並讓系統管理員為它們找出最佳值。
這樣的方法在短期內會使你的生活更容易，但它們會增加復雜性，因此許多人必須處理一個問題，而不是一個人。例如，如果一個類拋出一個異常，那么該類的每個調用者都必須處理它。如果類導出配置參數，則每個安裝中的每個系統管理員都必須學習如何設置它們。
8.1 示例：編輯器文本類
考慮為GUI文本編輯器管理文件文本的類，這在第6章和第7章中討論過。該類提供了將文件從磁盤讀入內存、查詢和修改文件在內存中的副本以及將修改后的版本寫回磁盤的方法。當學生必須實現這個類時，他們中的許多人選擇了一個面向行的接口，該接口具有讀取、插入和刪除整行文本的方法。這導致了類的簡單實現，但也為更高級別的軟件帶來了復雜性。在用戶界面級別，操作很少涉及整行。例如，擊鍵會導致在現有行中插入單個字符;復制或刪除選擇項可以修改幾個不同行的部分。使用面向行的文本界面，為了實現用戶界面，高級軟件必須分割和連接行。
面向字符的接口(如6.3節中描述的接口)將復雜性拉低。用戶界面軟件現在可以插入和刪除任意范圍的文本，而不需要分割和合並行，因此變得更加簡單。text類的實現可能會變得更加復雜:如果它在內部將文本表示為行集合，那么它將不得不分割和合並行來實現面向字符的操作。這種方法更好，因為它封裝了文本類中分割和合並的復雜性，從而降低了系統的整體復雜性。
8.2 示例：配置參數
配置參數是一個向上而不是向下移動復雜性的例子。類可以導出一些控制其行為的參數，而不是在內部確定特定的行為，例如緩存的大小或放棄之前重試請求的次數。然后該類的用戶必須為參數指定適當的值。配置參數在當今的系統中非常流行;有些系統有數百個。
支持者認為配置參數是好的，因為它們允許用戶根據自己的特定需求和工作負載調整系統。在某些情況下，底層基礎結構代碼很難知道應用的最佳策略，而用戶對他們的域要熟悉得多。例如，用戶可能知道某些請求比其他請求的時間要求更嚴格，因此用戶為這些請求指定更高的優先級是有意義的。在這種情況下，配置參數可以在更廣泛的領域內獲得更好的性能。
然而，配置參數也為避免處理重要問題並將其傳遞給其他人提供了一個簡單的借口。在許多情況下，用戶或管理員很難或不可能確定參數的正確值。在其他情況下，只需在系統實現中做一點額外的工作，就可以自動確定正確的值。考慮一個必須處理丟失的包的網絡協議。如果它發送了一個請求，但是在特定的時間段內沒有收到響應，它將重新發送請求。確定重試間隔的一種方法是引入配置參數。但是，傳輸協議可以自己計算一個合理的值，方法是測量成功請求的響應時間，然后對重試間隔使用該時間的倍數。這種方法降低了復雜性，使用戶不必確定正確的重試間隔。它還具有動態計算重試間隔的額外優點，因此如果操作條件發生變化，它將自動調整。相反，配置參數很容易過時。
因此，您應該盡可能避免配置參數。在導出配置參數之前，先問問自己:“用戶(或更高級別的模塊)能夠確定比我們在這里確定的更好的值嗎?”當你創建配置參數時，看看你是否能自動計算出合理的默認值，這樣用戶只需要在特殊情況下提供值。理想情況下，每個模塊應該完全解決一個問題;配置參數導致解決方案不完整，增加了系統的復雜性。
8.3 做過了頭
當把復雜性往下傳遞時要謹慎，這種想法很容易被誇大。一種極端的方法是將整個應用程序的所有功能都放到一個類中，這顯然是沒有意義的。如果(a)被降低的復雜性與類的現有功能密切相關，(b)降低復雜性將導致應用程序中其他地方的許多簡化，(c)降低復雜性將簡化類的接口，那么降低復雜性是最有意義的。請記住，目標是最小化整個系統的復雜性。
第6章描述了一些學生如何在反映用戶界面的text類中定義方法，例如實現backspace鍵功能的方法。這似乎是件好事，因為它將復雜性向下傳遞。但是，將用戶界面的知識添加到text類並不能簡化高級代碼，而且用戶界面知識也與text類的核心功能無關。在這種情況下，降低復雜性只會導致信息泄漏。
8.4 結論
在開發模塊時，尋找機會讓自己承擔一些額外的痛苦，以減少用戶的痛苦。