近日重新讀了一遍<設計模式>,結合自己的開發，專案經驗，談談自己的體會。
設計模式的目的：
1. 可重用性，開發人員常遇到的問題和解決問題的模式，自己可以拿來使用，拿來主義。
2. 公共詞彙，現在大部分開發人員都認可設計模式，並都能領會其含義，這樣便於開發人員針對問題的解決方案的溝通。
解決手段：
1.多用介面，少用繼承。現在好多框架也提倡這個理念，java開發中尤是。
2. 增加一箇中間類，例如：工廠，生成器，介面卡，中介，代理，橋接，裝飾器，訪問者，直譯器等。有的把物件的建立單獨拿出來作為一個類，有的在使用物件用一個新類來間接使用。
3. 在開發中多使用語言的新特色，能簡化程式設計。例如：泛型，泛型約束，LINQ，擴充套件函式。
4. .NET 技術本身就應用了很多設計模式，例如：WCF--代理。
結合自己現實專案，來具體談談。
首先不談具體程式設計，從整個產品線來看設計模式。
產品線建設，產品開發如果應用設計模式的理念能使一團亂麻，無法解決的複雜問題豁然開朗。
先簡單介紹一下產品線的背景：產品線包括一個整合平臺和十幾個子系統，整合平臺需要整合一個或多個子系統。產品線分為三個開發小組：前端開發，中間業務開發，採集層開發。應用到專案中時整合平臺需要根據實際需要生成不同的版本。
介紹了背景，第一個問題就出來了，子系統很多，要保證子系統正常執行，也要保證整合平臺的執行，我們如何開發基礎產品，開發步驟，開發原則？
第二個問題，隨著專案的增加，如果保證各個專案整合平臺的可維護性？各個專案的整合平臺的升級問題如何解決？
讓我們應用設計模式的一些理念來分析第一個問題。讓我們先默唸兩遍“產品線”這個詞，腦中應該會浮現出“工廠”，“抽象工廠”。
我們能不能用“抽象工廠”的概念來解決我們的產品線建設呢？
把三個開發小組看做三個工廠。他們需要遵循統一的開發步驟和設計規範。開發步驟和設計規範看做工廠介面。
把多個子系統看做產品系列。各個子系統需要遵循統一的產品規範。產品規範為產品介面。
例如：產品開發小組-GPS子系統前端 做為一個產品的建立過程。
產品建立完了，還有建立出子系統和整合平臺。其實建立子系統和整合平臺的過程可以用“Builder” 模式。把GPS前端，GPS中間層業務，GPS採集整合起來構成GPS子系統。GPS子系統，VES子系統，VMS子系統整合起來構成整合管理平臺。
從設計模式中我們應該體會到，產品線建設首先要確定統一的開發步驟和設計規範，每個開發小組貫徹執行之。其次每個開發小組要對自己開發部分有個統一的設計，形成架構或者規範。這樣在產品線建立過程中會流暢很多。其實現實非描述之簡單，複雜的多。以上觀點只是複雜的問題簡單化。
第二個問題也很關鍵，如果解決不好，隨著專案的增多，最後開發人員會疲於應付。例如發現一個BUG，或者解決了一個效能優化問題。如果解決多個專案同時升級。
我想到的是應用裝飾器模式，核心平臺建立完畢以後，各個專案在核心平臺的基礎上進行裝飾，不要更改核心平臺的程式碼。這樣以後不論核心平臺的升級還是專案的需求維護起來會簡單一些。 千萬不要一個專案一個核心平臺,核心平臺程式碼隨意更改。