盡量預測所有可能面臨的問題,按照等級划分並建立蝴蝶效應的樹狀結構圖.
日志系統是為運行期提供的,當然一些復雜的調試可能用得上.但日志是要提供有用的信息,而非毫無理由的try catch.try catch往往為了你不能預期且容易出問題的地方存在.
面向對象編程的優異在於便捷類重用,核心關鍵在於面向抽象編程.
越抽象的東西越不易變,所以核心的設計應該抽象出來.
面向過程的優異之處在於方法的重用方法重用,核心關鍵在於提煉方法策略便於重用
不要做重復的事情.
工作如此,同樣編碼設計亦如此.
當我們在兩個或多個地方的時候發現一些相似的代碼的時候，我們需要把他們的共性抽象出來形一個唯一的新方法，並且改變現有的地方的代碼讓他們以一些合適的參數調用這個新的方法。
當業務流程相同,而具體實現 不一致的時候.我們應該面向抽象
接口的類型分為命令和查詢兩種方式,不要同時干兩件事情.
切勿過度設計,用不上的東西你就不要去做.
不要自我復制
編程設計隨談
DRY 是一個最簡單的法則，也是最容易被理解的。但它也可能是最難被應用的（因為要做到這樣，我們需要在泛型設計上做相當的努力，這並不是一件容易的事）。它意味着，當我們在兩個或多個地方的時候發現一些相似的代碼的時候，我們需要把他們的共性抽象出來形一個唯一的新方法，並且改變現有的地方的代碼讓他們以一些合適的參數調用這個新的方法。
面向接口編程
這是設計模式中最根本的哲學，注重接口，而不是實現，依賴接口，而不是實現。接口是抽象是穩定的，實現則是多種多樣的。以后面我們會面向對象的SOLID原則中會提到我們的依賴倒置原則，就是這個原則的的另一種樣子。還有一條原則叫 Composition over inheritance（喜歡組合而不是繼承），這兩條是那23個經典設計模式中的設計原則。
命令-查詢分離原則
查詢：當一個方法返回一個值來回應一個問題的時候，它就具有查詢的性質；
命令：當一個方法要改變對象的狀態的時候，它就具有命令的性質；
通常，一個方法可能是純的Command模式或者是純的Query模式，或者是兩者的混合體。在設計接口時，如果可能，應該盡量使接口單一化，保證方法的行為嚴格的是命令或者是查詢，這樣查詢方法不會改變對象的狀態，沒有副作用，而會改變對象的狀態的方法不可能有返回值。也就是說：如果我們要問一個問題，那么就不應該影響到它的答案。實際應用，要視具體情況而定，語義的清晰性和使用的簡單性之間需要權衡。將Command和Query功能合並入一個方法，方便了客戶的使用，但是，降低了清晰性，而且，可能不便於基於斷言的程序設計並且需要一個變量來保存查詢結果。
在系統設計中，很多系統也是以這樣原則設計的，查詢的功能和命令功能的系統分離，這樣有則於系統性能，也有利於系統的安全性。
面向對象的一些原則問題.
1.高內聚， 低耦合
2.依賴倒置原則(核心抽象不考慮具體實現需要什么,而是提供抽象)
3.接口隔離原則(沒有關聯的接口就不要放一起了)
4.里氏代換原則(子類能夠完成父類的業務)
5.開閉原則(對擴展是開放的，而對修改是封閉的。 ) 寧增勿改
6.單一職責遠程(一個類，只做一件事，並把這件事做好，其只有一個引起它變化的原因。)