一、當你的專案發現有如下問題之一時，就需要考慮重構**，可能會有某種模式適合。
1、**無法進行單元測試。
2、需求的變動總是導致**的變動。
3、有重複**的存在。
4、繼承層次過多。
5、隱藏的依賴過多。
二、uml表示法
1、uml類圖
"+"代表public，「#」代表protected，「-」代表private，即
代表變數 public string prol;
代表方法 public void method1（）
2、uml序列圖
序列圖描述系統的動態互動過程，在序列圖中，垂直虛線叫做「生命線」，代表乙個物件的生存週期，每乙個箭頭代表乙個呼叫，
在生命線上若有空心條，代表呼叫的啟用週期，成為啟用條。
三、系統的可維護性包括如下幾個方面：
1、可擴充套件性：有了新的需求，新的效能可以容易地新增到系統中，並且不影響現有的效能，也不會帶來新的缺陷。
2、可修改性：系統某一部分的**需要修改時不會破壞系統現有的結構，也不會影響到其他部分。
3、可替換性：可以將系統中的某些類替換為相同介面的其他類，並且系統不受影響。
四、「開-閉」原則：
指軟體實體應當對擴充套件開放，對修改關閉，即軟體實體應該在不修改的前提下擴充套件。
五、封裝變化
程式中任何可能發生變化的部分都可以封裝為物件，包括命令、事件、屬性、演算法、形態等。
封裝變化是實現「開-閉」原則的重要手段，也是在設計中發現物件的重要途徑。
因此在分析需求時，一定要注意什麼是變的，什麼是可能發生變化的，以及這些可能的變化會對封裝帶來的影響。
六、面向介面程式設計的優勢：
1、降低程式各部分之間的耦合性，使程式模組互換成為可能。這樣客戶無需知道自己使用的物件型別，只要物件有客戶所期望的介面即可。
並且物件也不需要知道物件是如何實現的，只要知道定義介面的抽象類。
2、使軟體各部分便於單元測試，通過編制與介面一致的模擬類（mock），可以很容易地實現軟體各部分的單元測試。從而提高軟體的可靠性，降低錯誤率。
3、易於實現軟體模組的互換，軟體公升級時可以只部署發生變化的部分，而不會影響其他部分。
七、繼承的缺點
1、繼承在編譯時定義，無法在執行時改變，無法在執行時動態的選擇繼承或者不繼承某乙個類。
2、繼承對子類暴露了父類的實現細節，從而破壞了封裝性。
3、子類和父類耦合性非常強，一旦父類發生變化，必然導致子類也發生變化。
八、設計模式解決的問題
問題設計模式
描述通過顯示指定類建立物件
抽象工廠模式、工廠方法模式、原型模式
在例項化時，間接建立物件
緊耦合抽象工廠模式、命令模式、外觀模式、中介者模式、觀察者模式和職責鏈模式等
類之間需松耦合
通過生成子類擴充套件功能
橋接模式、職責鏈模式、組合模式、裝飾模式、觀察者模式、策略模式等
通過生成子類來擴充套件功能會產生很多問題，如引起子類數量大量增加和類層次的增加。
通過物件組合技術實現功能擴充套件是更好的選擇
對物件表示或實現的依賴
抽象工廠模式、橋接模式、備忘錄模式、**模式等
對客戶隱藏物件如何表示、儲存、定位或實現等。
不能方便地修改類
介面卡模式、裝飾模式、訪問者模式
對演算法的依賴
生成器模式、迭代器模式、策略模式、模板模式、訪問者模式
演算法實現的目的是不變的，但演算法本身卻不是一成不變的
對軟硬體環境的依賴
抽象工廠模式、橋接模式等
九、設計模式所用到的介面和類（.net）
介面/類
設計模式
描述icloneable
原型模式
這個介面支援轉殖，即建立與當前例項相同的例項，方法為clone（）
ienumerable/ienumerator
迭代子模式
公開列舉數支援在集合上進行簡單迭代
menucommand類/imenucommandservice
命令模式
提供了對自定義元件行為的基類
collectionbase類
組合模式、命令模式、享元模式、觀察者模式
collectionbase是強制型別集合的基類，通過實現這個類可以實現強制型別
idataadapter
介面卡模式
idataadapter定義了資料庫與dataset之間的橋接器，
針對不同的資料來源的dataadapter瞌睡實現程式與資料來源的松耦合
十、設計模式的分類
1、建立型模式
通過乙個專門例項化的類來獲得具體的物件，通常我們將稱這個類為「工廠」，將與例項化相關的模式稱為「建立型模式」。
設計模式一 簡單工廠模式（Unity C ）
設計模式一 簡單工廠模式 說到簡單工廠模式，說明此模式是用來生產的，也就是用來建立例項，我們平常的例項化就是new乙個物件，可如果要生產多個不同的物件應該怎麼辦？我們對例項化物件進行管理，也就是說想要乙個例項，不需要在乎這個例項是如何產生的，傳入乙個型別 特定字串 特定int 等，就能收到乙個標識該...
設計模式思考
高層模組不應該依賴於底層模組，應該在他們之間建立乙個抽象層，來實現可替換的底層，不變的介面層。這個是物件導向的更高境界了，面向介面程式設計。上層和下層通過唯一途徑聯絡就是介面，這有點類似與作業系統和軟體和硬體之間的關係，他們的聯絡也是通過能夠接觸到那一層介面來實現。可以說我們只需知道介面就能完成呼叫...
設計模式 單例設計模式的思考
單列設計模式 就本人理解，所謂的單例就是在程式執行的整個週期，類的例項僅存在乙個。餓漢式 餓漢式的設計 public classsington 獲取例項 public staticstudent getinstance 但是仔細想想餓漢式的設計方式存在乙個弊端就是在類載入的時候相關變數就會被例項 化...