第四章——模塊性。

模塊有兩個很重要的特性，緊湊性和正交性。
緊湊性是指小，擁有較少的public method 數量，能一次看到全貌。雖然書中提倡的10個public method 每個模塊，但是難于做到，但是15個以下，還是能做到的。
正交性是“每次只作一件事并做好”的學術詞。非正交的method的缺陷是副作用，因為在一次過程中實現了兩個事情，或者更具體的說，是函數體內實現了函數名說沒有說過要做的事情，并且這件事改變了模塊的狀態。舉個手頭上的例子：一個物理對象基類(IPhysxObject)有一個函數計算其子幾何體的總質量，名稱是_computeTotalMass(dMass &mass)。我在遍歷所有幾何體算出總質量后，把其設置為物理對象的當前質量——這就非正交了，因為多做了一件事：改變對象的質量。如果把函數名改為_updateMass(void)，就沒有什么問題。
非正交帶來的副作用，雖然說目前熟悉的項目中沒問題，但問題是如果你有機會重用這些非正交的模塊，你很可能忘卻了它帶有副作用的地方，或者發現了，卻需要額外的代碼來抑制副作用。

軟件是多層的。在層的設計與實現過程中（自頂向下和自底向上）會出現膠合層。膠合層這個概念很難理解，即使現在仍不能說是理解正確。書上所說是“頂層邏輯和底層原語集阻抗匹配的產物”，軟件是通過頂層邏輯加上依賴調用底層原語的函數實現其功能的，那么膠合層是否可以理解為原語調用？那么，所謂的薄膠合，便是從頂層到真正的調用底層原語，其中經歷了較少層次的函數調用嵌套。
C被視為薄膠合的語言，我看不出來（缺少根本上的代碼量）；但是C++作為厚膠合的典范可是很有感觸。厚膠合源于類繼承層數，即使只是兩層，仍會產生很普遍的麻煩，而且這其中還涉及到基類的變量是protected還是private的問題（我以前比較支持private，認為：如果子類需要使用這些變量的話，可以在基類中添加protected的使用原語，退一步還可以添加accessor）。舉手頭上的例子：
d1.Touch(d2)，需要訪問d2的mpEnt(protected)，即使是同一基類，到了子類中也是非法的。解決的辦法如友元，或者是一個public accessor，或者將D1::Touch實現的功能在Base中做一個原語，但是都不太舒服，不是嗎？友元者，對于數量龐大的子類間兩兩友元，需要多少心力呢？public accessor者，成員變量傳統上是不public的，即使accessor，如果返回成員的指針或者引用，那和直接public成員又有多少差別呢？原語者，只是把子類的功能提升到基類實現，然后子類在寫Touch函數的時候簡單的調用原語。太多原語實現存放在基類，使得基類的尺寸龐大，真的好嗎？如果子類要實現的功能不僅涉及基類成員，還涉及子類成員，怎樣處理？作為原語引用參數傳遞，還會直觀嗎？
有點顯然的，accessor，或者基類原語，都不斷增加膠合的厚度，因為你總是先要call一個只有一行實現的接口——然后才調用真正的實現，而且真正的實現中，肯定還會有其他執行類似與這種厚膠合···
厚膠合的真正缺陷并不在于函數調用效率，即使調用級數再高也不是主要問題。真正的缺陷是代碼的透明性——由于膠合過于雄厚，容易忽略某些零碎的細節，bug之地難以發現，或者code review的時候，完全沒有辦法看清全貌。
與之相比，C所以平坦，可以說是它沒有繼承（模仿會使得代碼更復雜），同時，訪問完全是public的。

<code id="42myy"></code>