no1：
單一職責原則提出了乙個編寫程式的標準，用「職責」或「變化原因」來衡量介面或類設計得是否優良，但是「職責」和「變化原因」都是不可度量的，因專案而異，因環境而異。
no2：
在類中呼叫其他類時務必要使用父類或介面，如果不能使用父類或介面，則說明類的設計已經違背了lsp原則
no3：
如果子類不能完整地實現父類的方法，或者父類的某些方法在子類中已經發生「畸變」，則建議斷開父子繼承關係，採用依賴、聚集、組合等關係代替繼承。
no4：
子類方法的前置條件必須與超類中被覆寫的方法的前置條件相同或者更寬鬆
no5：
依賴的三種寫法
1）建構函式傳遞依賴物件
2）setter方法傳遞依賴物件
3）介面宣告依賴物件
no6：
根據介面隔離原則拆分介面時，首先必須滿足單一職責原則。
no7：
迪公尺特法則要求類「羞澀」一點，盡量不要對外公布太多的public方法和非靜態的public變數，盡量內斂，多使用private、package-private、protected等訪問許可權。
no8：
如果乙個方法放在本類中，既不增加類間關係，也對本類不產生負面影響，那就放置在本類中
no9：
開閉原則對擴充套件開放，對修改關閉，並不意味著不做任何修改，低層模組的變更，必然要有高層模組進行耦合，否則就是乙個孤立無意義的**片段
no10：
no11：
有n個產品族，在抽象工廠類中就應該有n個建立方法
有m個產品等級就應該有m個實現工廠類，在每個實現工廠中，實現不同產品族的生產任務
no12：
在軟體開發過程中，如果相同的一段**複製過兩次，就需要對設計產生懷疑，架構師要明確地說明為什麼相同的邏輯要出現兩次或更多次
no13：
為了防止惡意的操作，一般模板方法都加上final關鍵字，不允許被覆寫。
no14：
抽象模板中的基本方法盡量設計為protected型別，符合迪公尺特法則，不需要暴露的屬性或方法盡量不要設定為protected型別。實現類若非必要，盡量不要擴大父類中的訪問許可權
no15：
要實現動態**的首要條件是：被**類必須實現乙個介面，回想一下前面的分析吧。當然了，現在也有很多技術如cglib可以實現不需要介面也可以實現動態**的方式
no16：
這種不通過new關鍵字來產生乙個物件，而是通過物件複製來實現的模式就叫做原型模式
no17：
物件拷貝時建構函式確實沒有被執行，這點從原理來講也是可以講得通的，object類的clone方法的原理是從記憶體中（具體地說就是堆記憶體）以二進位製流的方式進行拷貝，重新分配乙個記憶體塊，那建構函式沒有被執行也是非常正常的了
no18：
使用原型模式時，引用的成員變數必須滿足兩個條件才不會被拷貝：一是類的成員變數，而不是方法內變數；二是必須是乙個可變的引用物件，而不是乙個原始型別或不可變物件
no19：
深拷貝和淺拷貝建議不要混合使用，特別是在涉及類的繼承時，父類有多個引用的情況就非常複雜，建議的方案是深拷貝和淺拷貝分開實現
no20：
要使用clone方法，類的成員變數上不要增加final關鍵字
no21：
為什麼同事類要使用建構函式注入中介者，而中介者使用getter/setter方式注入同事類呢？這是因為同事類必須有中介者，而中介者卻可以只有部分同事類
no22：
在責任鏈模式中乙個請求傳送到鏈中後，前一節點消費部分訊息，然後交由後續節點繼續處理，最終可以有處理結果也可以沒有處理結果，讀者可以不用理會什麼純的、不純的責任鏈模式。
no23：
在裝飾模式中，必然有乙個最基本、最核心、最原始的介面或抽象類充當component抽象構件。
no24：
原始方法和裝飾方法的執行順序在具體的裝飾類是固定的，可以通過方法過載實現多種執行順序
no25：
策略列舉是乙個非常優秀和方便的模式，但是它受列舉型別的限制，每個列舉項都是public、final、static的，擴充套件性受到了一定的約束，因此在系統開發中，策略列舉一般擔當不經常發生變化的角色
no26：
no27：
只要是樹形結構，就要考慮使用組合模式，這個一定要記住，只要是要體現區域性和整體的關係的時候，而且這種關係還可能比較深，考慮一下組合模式吧
no28：
組合模式有兩種不同的實現：透明模式和安全模式。
透明模式是把用來組合使用的方法放到抽象類中，比如add()、remove()以及getchildren等方法，不管葉子物件還是樹枝物件都有相同的結構，通過判斷是getchildren的返回值確認是葉子節點還是樹枝節點，如果處理不當，這個會在執行期出現問題，不是很建議的方式（解決方法是拋異常）；
安全模式就不同了，它是把樹枝節點和樹葉節點徹底分開，樹枝節點單獨擁有用來組合的方法，這種方法比較安全
no29：
定義被觀察者必須實現的職責，它必須能夠動態地增加、取消觀察者。它一般是抽象類或者是實現類，僅僅完成作為被觀察者必須實現的職責：管理觀察者並通知觀察者。
no30：
觀察者模式和責任鏈模式的最大區別就是觀察者廣播鏈在傳播的過程中訊息是隨時更改的，它是由相鄰的兩個節點協商的訊息結構；而責任鏈模式在訊息傳遞過程中基本上保持訊息不可變，如果要改變，也只是在原有的訊息上進行修正
no31：
在物件池中，物件一旦產生，必然有乙個唯一的、可訪問的狀態標誌該物件，而且池中的物件宣告週期是由池容器決定，而不是由使用者決定的
no32：
在程式開發中，確認只需要一次賦值的屬性則設定為final型別，避免無意修改導致邏輯混亂，特別是session級的常量或變數
no33：
如果把乙個物件作為map類的鍵值，一定要確保重寫了equals和hashcode方法，否則會出現通過鍵值搜尋失敗的情況，例如map.get(object)、map.contains(object)等會返回失敗的結果
no34：
dos視窗命令nslookup--檢視網域名稱對應的ip位址
no35：
設計原則只是乙個理論，而不是乙個帶有刻度的標尺，因此在系統設計中不應該把它視為不可逾越的屏障，而是應該把它看成是乙個方向標，盡量遵守，而不是必須恪守
no36：
***是會影響系統效能的，所有的action在執行前後都會被***過濾一遍，即使不符合攔截條件的也會被檢查一遍，所以非必要情況不要使用***。
no37：
父類依賴子類的情景只有在非常明確不會發生變化的場景中存在，它不具備擴充套件性，是一種固化而不可變化的結構。
設計模式之禪
設計模式之禪 大話面向初學者 禪面向有了一定基礎後提公升能力的讀者 看大話，只是看故事，只是感性認識，對於很多初學者而又沒專案經驗 或 閱讀 編寫量 的人來說，比較適合用於入門 看禪 主要是有一定的專案經驗 或 閱讀 編寫量 基礎上，而又大致閱讀過23種設計模式中的20種以上基本概念後，再深化提公升...
設計模式之禪之設計模式 門面模式
1 package com.yeepay.sxf.template18 2 3 寫信的業務類 4 隱藏在門面角色裡邊，不需要暴露太多5 author sxf6 7 8public inte ce iletterprocess view code 寫信的業務類的實現 1 package com.yee...
設計模式之禪之設計模式 橋梁模式
1 package com.yeepay.sxf.template24 2 3 實現化角色 4 相當於不同的業務邏輯，抽象出共有行為5 6 產品類7 author sxf8 9 10 public abstract class product view code 房子產品實現 1 package c...