類是不是越小越好？最近在讀John Ousterhout的《A Philosophy of Software Design》，感到作者文筆流暢，書中內容具有啟發性。這裡摘要一部分內容，以供參考、學習。 本文鏈接：https://www.cnblogs.com/hhelibeb/p/10708951. ...
類是不是越小越好？最近在讀John Ousterhout的《A Philosophy of Software Design》，感到作者文筆流暢，書中內容具有啟發性。這裡摘要一部分內容，以供開發相關工作中的參考、學習。
本文鏈接：https://www.cnblogs.com/hhelibeb/p/10708951.html
轉載請註明
在軟體複雜度的管理當中，最重要的技術之一是通過對系統的設計，使開發者任何在時候都只需要面對整個複雜度中的一小部分。這個過程被稱為模塊化設計。
1，模塊化設計
在模塊設計中，軟體系統被分解為相對獨立的模塊集合。模塊的形式多種多樣，可以是類、子系統、或服務等。在理想的世界中，每個模塊都完全獨立於其它模塊：開發者在任何模塊中工作的時候，都不需要知道有關其它模塊的任何知識。在這種理想狀態下，系統複雜度取決於系統中複雜度最高的模塊。
當然，實踐與理想不同，系統模塊間總會多少有些依賴。當一個模塊變化時，其它模塊可能也需要隨之而改變。模塊化設計的目標就是最小化模塊間的依賴。
為了管理依賴，我們可以把模塊看成兩部分：介面和實現。
介面包含了全部的在調用該模塊時需要的信息。介面只描述模塊做什麼，但不會包含怎麼做。
完成介面做出的承諾的代碼被稱為實現。
在一個特定模塊內部進行工作的開發者必須知道的信息是：當前模塊的介面和實現+其它被該模塊使用的模塊的介面。他不需要理解其它模塊的實現。
在本文中，包含介面/實現的任何代碼單元，都是模塊。面向對象語言中的類是模塊，類中的方法也是模塊，非面向對象語言中的函數也是模塊。高層子系統和服務也可以被看作模塊，它們的介面也許是多種形式的，比如內核調用或HTTP請求。本文中的大部分內容針對的是類，但這些技術和理論對其它類型的模塊也有效。
好模塊的介面遠遠比實現更簡單。這樣的模塊有2個優點。首先，簡單的介面最小化了模塊施加給系統其餘部分的複雜度。其次，如果修改模塊時可以不修改它的介面，那麼其他模塊就不會被修改所影響。如果模塊的介面遠遠比實現簡單，那麼就更有可能在不改動介面的情況對模塊進行修改。
2，介面里有什麼
介面中包含2種信息：正式的和非正式的。
正式的信息在代碼中被顯式指定，程式語言可以檢查其中的部分正確性。比如，方法的簽名就是正式的信息，它包含參數的名稱和類型，返回值的類型，異常的信息。很多程式語言可以保證代碼中對方法的調用提供了與方法定義相匹配的參數值。
介面裡面也包含非正式的元素。非正式部分無法被程式語言理解或強制執行。介面的非正式部分包含一些高層行為，比如函數會根據某個參數的內容刪除具有相應名字的文件。如果某個類的使用存在某種限制，比如方法的調用需要符合特定順序，那這也屬於介面的一部分。凡是開發者在使用模塊時需要瞭解的信息，都可以算作模塊介面的一部分。介面的非正式信息只能通過註釋等方式描述，程式語言無法確保描述是完整而準確的。大部分介面的非正式信息都比正式信息要更多、更複雜。
清晰的介面定義有助於開發者瞭解在使用模塊時需要知道的信息，從而避免一些問題。
3，抽象
抽象這一術語和模塊設計思想的關係很近。抽象是實體的簡化視圖，省略了不重要的細節。抽象很有用，它可以使對細節的思考和操縱變簡單。
在模塊化編程中，每個模塊通過介面提供其抽象。抽象代表了函數功能的簡化視圖。在函數抽象的立場上，實現的細節是不重要的，所以它們被省略了。
“不重要”這個詞很關鍵。如果沒有忽略掉不重要的細節，那麼抽象會變得複雜，會增加開發者的認知負擔；如果忽略掉了重要的細節，那麼抽象會變得錯誤，失去對實踐的指導意義。設計抽象的關鍵是理解什麼是重要的，並尋找最小化重要信息的設計。
依賴抽象來管理複雜度不是編程的專利，它遍佈在我們的日常生活中。就像車子會提供一個簡單抽象來讓我們駕駛，並不需要我們理解發動機、電池、ABS之類的東西。
4，深模塊
最好的模塊提供了強大的功能，又有著簡單的介面。術語“深”可以用於描述這種模塊。為了讓深度的概念可視化，試想每個模塊由一個長方形表示，如下圖，
長方形的面積大小和模塊實現的功能多少成比例。頂部邊代表模塊的介面，邊的長度代表它的複雜度。最好的模塊是深的：他們有很多功能隱藏在簡單的介面後。深模塊是好的抽象，因為它只把自己內部的一小部分複雜度暴露給了用戶。
淺模塊的介面複雜，功能卻少，它沒有隱藏足夠的複雜度。
可以從成本與收益的角度思考模塊深度。模塊提供的收益是它的功能。模塊的成本（從系統複雜度的角度考慮）是它的介面。介面代表了模塊施加給系統其餘部分的複雜度。介面越小而簡單，它引入的複雜度就越少。好的模塊就是那些成本低收益高的模塊。
某些語言中的垃圾回收（GC）是深模塊的例子之一。這個模塊沒有介面，它在需要回收無用記憶體的場景下不可見地工作。在系統中加入垃圾回收縮小了系統的總介面，因為這種做法消除了用於釋放對象的介面。垃圾回收的具體實現是相當複雜的，但這一複雜度在實際使用程式語言的時候被隱藏了。
5，淺模塊
相對的，淺模塊就是介面相對功能而言很複雜的模塊。下麵是個可能有些極端的例子，
private void addNullValueForAttribute(String attribute) { data.put(attribute, null); }
從複雜度管理的角度來看，該方法把事情變糟了。它沒有提供抽象，因為所有的功能都是在介面上可見的。思考這一介面並不會比思考它的完整實現更簡單。如果方法有合適的文檔，文檔也不會比方法的代碼具有更多信息。相比於直接操作data，它的長名字甚至會導致開發者敲擊鍵盤的次數變多。這種方法增加了複雜度（引入了一個需要開發者瞭解的新介面），但並沒有提供與之相應的收益。註意：小的模塊會更傾向於變淺。
6，Classitis
當今，深模塊的價值並沒有被廣為接受。一般常識是類需要小，而不是深。學生們被告知：類設計中最重要的事情是把大類拆分成更小的類。相似的建議還包括：“要把方法行數大於N的方法分成多個方法”，有時候N甚至可以像10這麼小。這會導致大量的淺模塊，增加系統的總複雜度。
把極端的“類應該小”是一種綜合症，可以被稱為Classitis。它源於一種錯誤思維：“類是好的，所以越多類越好”。這種思想最終會導致系統層面積累了巨大的複雜度，程式風格也會變得啰嗦。
7，例子
Java類庫可能是Classitis的最明顯例子之一。Java語言本身不需要很多小類，但Classitis文化可能已經在Java語言社區扎了根。比如，為了打開文件讀取其中的序列化對象，你必須創建多種對象：
FileInputStream fileStream =
new FileInputStream(fileName);
BufferedInputStream bufferedStream =
new BufferedInputStream(fileStream);
ObjectInputStream objectStream =
new ObjectInputStream(bufferedStream);
FileInputStream對象只提供初步的I/O，它不具備緩存I/O的能力，也不能讀寫序列化對象。BufferedInputStream和ObjectInputStream分別提供了後面兩項功能。文件打開之後，fileStream和bufferedStream就沒用了，未來的操作只會用到objectStream.。
必須顯式單獨創建BufferedInputStream對象來請求緩存，這很煩人而且易出錯。如果開發者忘記創建它，就不會有緩存，而且I/O會慢。大概Java開發者會辯解說，不是所有人都需要緩存，所以它不應該包含在基本讀寫機制中。他們也許會說讓緩存獨立更好，藉此用戶可以選擇是否使用它。提供選擇空間當然很好，但介面需要設計為對常用場景儘可能簡單，幾乎所有文件I/O用戶都想使用緩存，所以就應該預設提供它。對於少數不需要的情況，庫可以提供機制以禁用。禁用緩存的機制應該明確地在介面中分離（例如，為FileInputStream提供不同的構造器，或者通過一個方法禁用/替換緩存機制），這樣大部分開發者甚至不需要意識到它的存在。
8，結論
通過將模塊的介面和實現分離，我們可以對系統的其它部分隱藏實現的複雜度。模塊的使用者只需要理解介面提供的抽象。在設計類和其它模塊時，最重要的問題是讓它們深，它們要對常見用例有足夠簡單的介面，但還是提供強大的功能。這就最大化地隱藏了複雜度。
