1、多維度分析。
2、適用於有可能多個維度組合形成乙個場景，並且各個維度可能分別演化的場景
3、為自己工作，為自己的系統工作，做自己的老闆，形成正迴圈：打磨當前工作的核心關鍵能力——>高效能工作——>更多時間打磨自己的系統——>更高效能工作——>打磨下個層次工作的核心關鍵能力……
4、核心競爭力，是指你擁有的（獨特的）知識經驗組合，經過你思維邏輯的組織梳理，在實踐中產生無可替代的價值。打造自己的tms系統（t：專業技術；m：溝通管理、s：行業解決方案），利用複利效應，讓系統為自己工作。
為什麼初學者有時候無法理解設計模式？
因為沒有遇到過問題，設計模式實際上是為了解決某種場景下的問題產生的優雅解決方案。
所以看了很多設計模式的書，由概念出發，反向舉例子與人的認知方向正好衝突。
設計模式的學習，應該通過問題引出，學習者有了自己的實現之後，再去給出設計模式的實現，經過對比才會讓學習者認識深刻，有一種思維上的爽快感！
並且，設計模式作為一種解決問題的模式工具，為什麼每本設計模式書裡面都要將類圖畫的那麼複雜？
不應該掌握其解決問題的適用場景，如果到了使用的時候，再去翻看一下書看下怎麼實現不就可以了嗎？
大腦用來思考，不是用來儲存。
中國話叫做：君子不器。
轉入正題
先給乙個結論：
橋梁模式，解決的是某個場景下，有多個維度分別演化的問題首先來看一下兩個問題：
讀者可以先思考一下自己如何實現。
我們首先進行維度分析（ooa）看一下一下場景描述。
這段描述裡面有兩個關鍵維度：通知型別、通知渠道。
維度1：通知型別，有可能是一般通知、緊急通知……這兩個維度，每乙個都是有可能單獨變化的。
簡單的類圖如下，核心原理就是拆解成單一維度，然後統一組裝，最大化的解耦：
每乙個外部系統的報文協議都不一樣。
一種最初級的簡陋方案是：每次都在web.xml中加上對映路徑（或者controller中加入），每乙個路徑都特殊處理。
但是，這種複雜的變動情況，肯定不符合程式設計師的審美觀。
物件導向開發的乙個大原則就是：
封裝變化對於這種場景，再進行一下維度分析。
我們可以看到，一次請求也有兩種維度：
通訊協議維度，例如http、socket、mq……
報文協議維度，webservice的soap報文、json格式報文、xml格式報文、定長字段格式報文等等而我們內部系統，通常有乙個自己的統一模型（假設叫做：requestmsg），我們要做的是要支援各種通訊協議、各種報文協議的組合變幻。
當然，如果企業內部有閘道器的話，這一層的轉換處理可能是在閘道器進行處理了，業務系統只需要處理業務即可了。
對於此部分的橋接模式處理類圖如下：
設計模式 橋梁模式
定義抽象公司 public abstract class corp 上方是模板方法 下面是房地產公司 public class housecorp extends corp 賣房子 protected void sell 賺錢 public void makemoney 服裝公司 public cl...
設計模式之橋梁模式
其實大家都是朋友，也不能人人都像小明那麼勢利吧。小剛就做的比較好，一打眼就知道誰是窮人誰又是富人了。不過沒關係窮人有窮人的玩法富人有富人的玩法嘛 這段邏輯用 怎麼實現？首先是乙個抽象的朋友 朋友在這裡充當了實現者角色 public abstract class friend 下來朋友裡有富有的有貧窮...
設計模式之橋梁模式
場景描述 1 在系統設計時，發現類的繼承有n層時，但不能確定是否會更改繼承來的共性，可以考慮使用橋梁模式。2 類圖描述 橋梁模式是抽象和實現的解耦，使得兩者可以獨立地變化。3 程式實現舉例 c using system using system.collections.generic using s...