按照讀書順序整理
述而不作
此版為草稿
第二部分：高質量代碼
第六章：可工作的類
a.好處
提高程序自說明性
隱藏細節
隔離復雜度
流暢的參數傳遞
容易重構
...
public下實質就是對外開放的接口，而private則是封裝的細節
ADT：應采用盡可能高的抽象
b.接口設計原則
1.一個類只實現一個ADT，內聚性要高。對類內雜亂的函數：
轉移到其他類里，
轉移為私用子函數
2.使用一致的抽象層次，混亂的抽象會讓程序難以理解：
事務層次的類不應該提供容器的操作窗口，
如果有操作需求，也應是事務概念的操作
3.接口是對捕捉到的抽象進行選擇，
4.檢查是否存在相反操作需求
5.一半子程序使用一半數據，另一半子 程序使用另外一半數據，那么拆分類吧。
6.盡量把語義接口元素轉化為編程接口元素。如使用斷言等。
總之，接口應該展示一致的抽象。
c.封裝原則
對c++等語言代碼中,不要在private部分暴露實現細節。
封裝方法是
private EmployImplymentation * m_implymenTation
而把細節放入implymentation類里。
至少讀代碼時別去私用部分里找細節
封裝是對接口編程，而不是對內部實現細節編程。
封裝的思維:
如果一個人調用庫時發現問題，不應該查閱源代碼，而是聯系作者去修改發布。類內實現細節不應該影響使用者編程。如：
邏輯過程缺失：perform內包含initial，沒讀細節的使用者先initial再perform就會出bug
假設過強：使用classA.num代替classB.num.客戶不知道他們兩個的num相同。
緊密耦合事實上消除了封裝性。
e.繼承
種類：
公有：class a:public class baseClass;
1.baseClass中public元素在a中還是public，base中private元素在a中不可見
2.代表 is a 關系
私有：class b:public class base
1.base中public元素在b中是private，base中private不可見
何時選擇繼承：
1.多個類的共有元素需要一個基類去集中
2.派生類必須能夠通過基類的接口直接調用
3.LSP原則：使用時無須思考不同派生類的語義含義，即基類提供之接口讓人直接理解派生類的行為如：
loanAccount的interest和saveAccount中interest中語義不同，就不應在基類account中放入interest元素，interest的繼承并沒有減少程序員的思考量
4.不要過度設計。為未來工作著想的方式是讓眼下之成果盡可能清晰簡單。---只有一個派生類的繼承很值得懷疑
5.case語句下多操作都很類似暗示著多態的需求。
而種類確實不同的操作則不必。
6.繼承體系盡可能低
幾點注意事項：
1.避免萬能類，應該把功能放入萬能類他所操作的類上去。
2.避免動詞命名的類：只有動作而無數據的類只應該是其他類的子程序。
在軟件的歷史中，粒度的增長帶來軟件開發的進步。語句-子程序-類-包等。
第七章：高質量子程序
a.子程序作用
1.子程序名提供邏輯抽象解釋
2.避免重復代碼
3.封裝事務過程
.......
b.設計
內聚性：
功能內聚性：只完成一個功能
順序內聚性：順序執行的操作由上一步ans求下一步
通信內聚性：操作共享數據但無其他聯系
臨時內聚 ：startup()等，不相關的操作組合在一起
邏輯內聚：通過傳入的控制字段選擇不同操作。如
inputAll（type）
對邏輯內聚：
不應該用一個程序控制另外一個程序的處理方式。
應把程序分為幾個平行程序在上層調用。若有相似的底層操作，則封裝成底層函數。
但如程序僅為if/case之內選擇不同函數，就成了常用的事件處理器。
c.函數命名
避免使用含糊的詞 如：HandleOutput->FormatAndPrint
找不到準確的詞說明子程序可能需要修改
描述程序做的所有事 ：一個動賓結構，object.function()則不必
或者描述程序的返回值
一個恰如其份但是糟糕的函數名說明需要重新設計
#######子程序長度一般應少于200行
d.參數
1.接口參數按一定順序排列，如：修改-輸入-輸出型參數
考慮命名規則
2.使用自己函數定義的工作變量,如:
int workingVal=inputVal workingVal....... //注意這兩個變量命名是很差的
3.盡量采用const關鍵字
4.以斷言或注釋解釋參數的操作類型數值范圍等
5.參數過多說明耦合緊密。人腦很難記住超過7個單詞
7.確保形參實參一致
8.傳遞數據成員還是對象：
--取決于抽象
函數不要返回局部變量
e.宏程序
1.參數要套括號==
2.整個表達式外要套括號
3.多條語句外套{}
4.除非必要，還是不要用了吧...
第六部分：變量
代碼被閱讀的時間遠遠大于編寫的時間，確保代碼閱讀方便。
一般事項
1.顯式聲明，初始化
2.就近聲明和初始化
3.讓變量的跨度和存活時間盡可能短以減少攻擊窗口。（盡量不使用全局變量)
把相關的語句放在一起
提取語句成為單獨的子程序
4.拋棄變量時賦不合理的NULL值
5.變量晚綁定值可以獲得靈活性（使用具名變量）
6.單個變量只用于單一用途
7.檢查是否有未使用的已聲明變量
變量命名
1.8到16個字符
2.體現問題而非解決方案
3.一致的命名變量。
如revenueTotal---expenseAverage
例外numCustomers
4.采用對仗詞如old-new，source-target
5.用比i，j，k更具意義的詞為大循環或多重循環的循環變量命名
6.temp說明程序員并沒有完全的搞懂問題。
7.done，found,error等布爾變量。
8.枚舉類型使用組前綴。
一.命名規則
1.命名規則為代碼增加了結構，是一項全局決策。
2.用g_標識全局變量
3.變量首字母小寫，函數首字母大寫。
