第四章——模塊性。

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

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