設計模式是一種真理，我們在沒有學習過設計模式時都會或多或少的與他不謀而合，但是學習過後我們可以把他從經驗性的東西提煉為理論性的，並且反過來再指導實踐，這應該就是我們學習並使用設計模式的初衷，這好比是政經中的價值規律，任何人都知道東西如果少了而需求大，它**馬上就漲，而反過來**就賤，可是學過政經後就可以站到理論高度了，把握起來更加從容
。設計模式中，用到過的可能不下十五種，具體的也沒有統計過，但令我印象最為深刻的，也是給我最大受益的還屬觀察者模式。
我做的是廣電系統的線纜設計模組，使用的是超圖提供的
gis控制項，使用過它的同行肯定知道，這個控制項提供了大量的訊息，包括最基本的滑鼠鍵盤訊息，還有一些特殊的訊息，比如新增了空間物件，開始的時候用這些訊息還是很方便的，畢竟人家也是千錘百鍊的，穩定性肯定有保障，可是開發了乙個月後，功能做了一部分，突然發現再加入新的功能已經舉步維艱，因為**量太大，而使用這樣的乙個訊息系統，各個關聯不大的功能之間也耦合緊密，看了半天覺得回到了過程時代，在手足無措之時想到了故交觀察者。
用觀察者模式來處理這樣的問題實在是游刃有餘，首先讓
subject
盯著控制項發出的各種訊息，然後將訊息分析後分發給各個
observer
，而這時的各個功能邏輯可以散布到各個觀察者中，耦合度急劇下降，而且各個觀察者的註冊與反註冊可以根據需要隨時進行，靈活性急劇增強，從而使整個系統可擴充套件性良好、可維護性提高、可重用性增強，為後續的開發工作提供了有力的保障
觀察者模式有點類似文件檢視結構中的updateallviews。
一般學設計模式的人都有過這樣的經歷：這模板模式怎麼我還沒學就用過了，哈哈
泛型是一種模板模式？
工廠模式、工廠方法模式和抽象工廠模式
可實現:可根據配置來連線資料庫，如sql server、oracle等即可。而不是new sqlconnect/oracleconnect。
工廠模式有點類似c#的反射、uno中的服務管理器:new("類名")
可以這麼去理解，「抽象工廠模式」這個稱呼中的「抽象」是乙個動詞，即對工廠方法模式進行了抽象，就變成了抽象工廠模式，這麼理解後，就不難看出它們的區別：
工廠方法模式：每個抽象產品派生多個具體產品類，每個抽象工廠類派生多個具體工廠類，每個具體工廠類負責乙個具體產品的例項建立；
抽象工廠模式：每個抽象產品派生多個具體產品類，每個抽象工廠派生多個具體工廠類，每個具體工廠負責多個（一系列）具體產品的例項建立。
在開發乙個類的過程中,我們一般都要為這個類開發相應的建構函式(不過大部分情況下,.net開發環境會自動預設建立建構函式),這樣,使用這個類的客戶可以利用建構函式對這個類進行例項化．但是，有時候會出現這種情況：需要使用乙個物件的客戶並不知道（或者不應該知道）應該對幾個類中的哪個類進行初始化．面對這個問題，我們可以利用工廠模式定義乙個介面，客戶可以使用這個介面建立乙個物件．同時我們還可以控制對哪個類進行例項化，例項化過程使用了乙個方法，這個方法需要利用外部因素來確定對哪個類進行例項化．有時候，這些外部因素就是乙個龐大的研究主題，並且往往會涉及到多個類．為此，抽象工廠模式就應用於這種場合，其目的是為了提供乙個建立一系列相關或相互依賴物件的介面，而無需指定它們具體的類
」，至少
「無需指定它們具體的類
」符合我們的要求。
毛筆與畫筆的區別
訪問者模式
策略模式
設計模式筆記
1 類繼承與介面繼承的比較。物件的類與物件的型別的比較 乙個物件的類定義了物件怎麼樣實現的，同時也定義物件內部狀態和操作的實現。但是物件的型別只與他的介面有關，藉口即物件能響應的請求的集合。乙個物件可以有多個型別，不同的類物件可以有相同的型別。理解類繼承和介面繼承之間的差別也十分重要。類繼承根據乙個...
設計模式筆記
設計模式精解p136，第11章 專家如何進行設計 alexander提到 從片段開始設計不是乙個好的設計方法。即將預先成型的部分新增在一起是無法得到優秀的軟體設計的。但還是可以得到可以工作的軟體的，只是大部分時候難於修改或擴充套件 我的觀點 軟體或者軟體系統都是由 功能模組 和這些 模組之間的聯絡 ...
設計模式筆記
黎克特制替換原則 父類能出現的地方，子類也能出現 子類盡量避免 個性 一旦把子類當作父類使用時子類的 個性 被抹殺掉 避免紛爭，規則壓制 子類繼承父類，如果子類要過載父類的方法，該方法的引數型別範圍要大於等於父類，返回引數要小於父類的返回型別 這樣避免混淆 依賴倒轉原則 1 建構函式傳遞依賴物件 p...