盡量**所有可能面臨的問題,按照等級劃分並建立蝴蝶效應的樹狀結構圖.
日誌系統是為執行期提供的,當然一些複雜的除錯可能用得上.但日誌是要提供有用的資訊,而非毫無理由的try catch.try catch往往為了你不能預期且容易出問題的地方存在.
物件導向程式設計的優異在於便捷類重用,核心關鍵在於面向抽象程式設計.
越抽象的東西越不易變,所以核心的設計應該抽象出來.
面向過程的優異之處在於方法的重用方法重用,核心關鍵在於提煉方法策略便於重用
不要做重複的事情.
工作如此,同樣編碼設計亦如此.
當我們在兩個或多個地方的時候發現一些相似的**的時候，我們需要把他們的共性抽象出來形乙個唯一的新方法，並且改變現有的地方的**讓他們以一些合適的引數呼叫這個新的方法。
當業務流程相同,而具體實現 不一致的時候.我們應該面向抽象
介面的型別分為命令和查詢兩種方式,不要同時幹兩件事情.
切勿過度設計,用不上的東西你就不要去做.
不要自我複製
程式設計設計隨談
dry 是乙個最簡單的法則，也是最容易被理解的。但它也可能是最難被應用的（因為要做到這樣，我們需要在泛型設計上做相當的努力，這並不是一件容易的事）。它意味著，當我們在兩個或多個地方的時候發現一些相似的**的時候，我們需要把他們的共性抽象出來形乙個唯一的新方法，並且改變現有的地方的**讓他們以一些合適的引數呼叫這個新的方法。
面向介面程式設計
這是設計模式中最根本的哲學，注重介面，而不是實現，依賴介面，而不是實現。介面是抽象是穩定的，實現則是多種多樣的。以後面我們會物件導向的solid原則中會提到我們的依賴倒置原則，就是這個原則的的另一種樣子。還有一條原則叫 composition over inheritance（喜歡組合而不是繼承），這兩條是那23個經典設計模式中的設計原則。
命令-查詢分離原則
查詢：當乙個方法返回乙個值來回應乙個問題的時候，它就具有查詢的性質；
命令：當乙個方法要改變物件的狀態的時候，它就具有命令的性質；
通常，乙個方法可能是純的command模式或者是純的query模式，或者是兩者的混合體。在設計介面時，如果可能，應該盡量使介面單一化，保證方法的行為嚴格的是命令或者是查詢，這樣查詢方法不會改變物件的狀態，沒有***，而會改變物件的狀態的方法不可能有返回值。也就是說：如果我們要問乙個問題，那麼就不應該影響到它的答案。實際應用，要視具體情況而定，語義的清晰性和使用的簡單性之間需要權衡。將command和query功能合併入乙個方法，方便了客戶的使用，但是，降低了清晰性，而且，可能不便於基於斷言的程式設計並且需要乙個變數來儲存查詢結果。
在系統設計中，很多系統也是以這樣原則設計的，查詢的功能和命令功能的系統分離，這樣有則於系統效能，也有利於系統的安全性。
物件導向的一些原則問題.
1.高內聚， 低耦合
2.依賴倒置原則(核心抽象不考慮具體實現需要什麼,而是提供抽象)
3.介面隔離原則(沒有關聯的介面就不要放一起了)
4.黎克特制代換原則(子類能夠完成父類的業務)
5.開閉原則(對擴充套件是開放的，而對修改是封閉的。 ) 寧增勿改
6.單一職責遠端(乙個類，只做一件事，並把這件事做好，其只有乙個引起它變化的原因。)
freeBSD中的一些設計思想
指導性架構設計原則 下面的指導性設計原則描述了我們的設計理念 摘自 scheifler gettys x window system 安全的設計方法 編寫安全的應用程式要帶著謹慎和略有悲觀的生活觀點。程式應該本著 最小特權 的原則執行，這樣就不會有帶著大於足夠能完成其功能的許可權的程序在執行。預先測...
一些設計思想的匯集 2
關於畫面內容的check的設計 首先定義介面 public inte ce ivalidator 及虛類public abstract class abstractvalidator set protected bool isemptystring object obj else public ab...
網路開發的一些總結
1 i o 模型的選擇，epoll就一定好嗎?那是肯定的。這個和select,poll有什麼區別。epoll還有比select,poll先進得地方，就在於將fd得列表維護在核心中，而select,poll是呼叫一次，傳遞一次，這點epoll領先是沒得說得。最主要還是epoll系統呼叫的實現方式採用事...