今天主要想談談Strategy(策略)模式。
先從一個例子開始吧，公司的系統中有一個功能，就是當我們的系統和別系統做接口(收發消息)的時候，由於我們的系統可能和多個外系統做這個動作，而對於兩個系統做通信來說，雖然我們現在是異步的實現，使用的IBM的消息中間件(MQ)，但是兩個系統必須首先在一起互相決定一下我們的消息格式和規範，這是系統之間能不能通信成功的一個關鍵所在，所以不管是從指定的Queue裏收消息，還是往指定的Queue裏發送消息，在數據準備好之前，我們必須還要進行一步數據格式的轉換，我們使用的都是XML格式的數據，這裏的轉換不是指跨數據格式的轉換，而是就XML而言，進行的轉換，比如：對方需要一個什麼樣格式的XML它纔可以去解析到正確的信息，我們需要對方是個什麼樣的格式過來，我們的系統才能夠正常的去工作。
針對於上面的這個情況，相信，大家的第一個反應是接口，具體實現類，然後根據不同的系統調用不同的具體實現類，然後執行下面的流程，收-->轉-->處理||轉-->發。
現在我們系統的實現方式也是這樣，定義了一個filter的接口，裏面封裝的轉換格式的業務方法，然後呢再根據不同的系統交互定義不同的class來實現這個接口並重寫這些轉換的業務方法，而至於客戶端程序是怎麼知道要具體調用哪個具體實現的class，是根據我們在參數裏配置的class名稱來決定的，所以系統會拿這個參數中寫的具體實現類名來造型，並得到一個實現此接口的對象實例，然後調用接口中定義的業務方法，進行處理。我想我對以上的這一套流程的描述，大家應該能夠清楚，不是很複雜的東西。繼續往下吧！
我們系統的這個設計是它本身的優點的，在一定程度上解耦合，基本上客戶程序不用關係具體我要走哪個實現類，參數配置了，而且我統一調接口的方法就可以完成我想要的工作了，靈活性也很高。
我認爲，我們這個設計就是個典型的策略模式，我個人認爲是一種更好的Strategy(策略)模式。
那麼什麼是策略模式，我認爲，還是要顧名思義，對於一個問題，就如我上面談到的消息格式轉換問題，可能會有很多個策略，或者說通俗點，就是會有多個實現方法，那麼對於客戶程序而言，我和你定了一個接口，至於接口背後要怎麼做我不知道，但是我知道你那個接口背後會有什麼人在幫我做，對於接口而言，你，客戶程序必須告訴我你要我的哪個實現來做這個事，要不我沒辦法幫你做事。接口其實不做事，相當於通信員，呵呵，是個規範而已，好了，於是策略模式一般的做法是在接口前再來個類，就是所謂的環境類，這個類裏有個接口的實例，是個數據成員，然後客戶成員用這個類，new的時候呢給我個具體的實現類，然後調用的這個環境類中的具體業務方法，就OK了，這個類我認爲是把接口再封裝了一層，有點那個意思，其實這個環境類中的業務方法無非就是調用接口中定義的那些方法罷了。不想寫代碼，所以就口述了，不知道能不能說清楚，大家見諒！
好了，典型的策略模式應該就是這樣了，那麼用了有什麼好處？
因爲使用這種模式的原因是我們的系統對於同一個類型的業務可能有很多個方法去實現，變化很多很快，不穩定，但是業務是一樣的，業務的流程也是相似的，就是具體實現方法不一樣，這樣我們使用策略模式就可以大大減少我們這些實現和客戶程序的耦合程度，如果我們添加新的實現策略就不需要改動客戶程序。非常靈活，方便。
但是最大的問題，我認爲是最不好的地方是，客戶程序必須要知道我是用的哪個策略，這無疑又把具體實現和客戶程序耦合起來了，如果我的具體實現名稱改了，那麼客戶程序可能就傻眼了。
第二個缺點，隨着策略的增多，類也會增多。
我們公司的設計我認爲是解決了我所認爲這個模式的最大的一個問題，如果說再做一層隔離，我客戶程序也不知道是要用哪個具體的策略去做事，而是由第三方來告訴我，那麼客戶程序就真正的和我們的策略實現解耦了，當代碼運行到我需要使用策略的時候我才知道是要用具體的哪個，這種方法就非常的靈活了，這樣一來，客戶程序也變的非常通用，複用程度會大大提高。根本就不需要那個環境類來根據你給的具體實現類來通過接口調度到具體的實現類中的方法。
以上是我個人的一點點想法，可能還有想得不周到的地方，一點心得吧，沒寫什麼代碼，很不好意思，希望能看得懂！