橋接模式的解析-iOS
橋接模式的解析-iOS
其他設計模式的介紹
1、ofollow,noindex" target="_blank">簡單工廠模式、工廠模式、抽象工廠模式的解析-iOS
2、建造者模式的解析-iOS
3、單例模式的解析-iOS
5、代理模式的解析-iOS
10、組合模式的解析-iOS
概率描述
橋接模式是將抽象部分與它的實現部分分離，使它們都可以獨立地變化。它是一種物件結構型模式，又稱為柄體(Handle and Body)模式或介面(Interface)模式。百度百科
角色
橋樑模式所涉及的角色有：
抽象化(Abstraction)角色：抽象化給出的定義，並儲存一個對實現化物件的引用。
修正抽象化(Refined Abstraction)角色：擴充套件抽象化角色，改變和修正父類對抽象化的定義。
實現化(Implementor)角色：這個角色給出實現化角色的介面，但不給出具體的實現。必須指出的是，這個介面不一定和抽象化角色的介面定義相同，實際上，這兩個介面可以非常不一樣。實現化角色應當只給出底層操作，而抽象化角色應當只給出基於底層操作的更高一層的操作。
具體實現化(Concrete Implementor)角色：這個角色給出實現化角色介面的具體實現。百度百科
實用場景
1、使用那些不需要通過繼承導致類的個數急劇增加的系統
2、就是抽象和實現可以自己獨立擴充套件，兩者之間互不影響
案例解析
在平常的生活中，我們都使用空調，可能大家都注意到了，如果你的空調遙控器壞了，我們都是在市場上配一個萬能的遙控器。你要你用空調的編碼序號繫結上空調就可以使用了。
這就涉及到一個問題：每個空調都需要對應一個自己型號的遙控嗎。
其實我們的空調開發商，都會生產很多型號的空調，這樣是不是每個空調種類都生產一個自己獨有的遙控器呢，如果這樣做那開發商需要生產很多種類的遙控器。但是我們空調好多的功能都是差不多的，我們其實可以把我們的遙控器設計成一個可以複用和擴充套件的遙控器。這樣我們就可以使用我們的橋接模式來設計。程式碼如下：
AbstractControl-是遙控器的抽象層
AbstractControl–遙控器真實呼叫層繼承自AbstractControl
AirConditionerProtocol—遙控器和空調之間的橋接點
AbstractAirConditioner–抽象的空調層
VertableAirConditionerA-真實的空調層，繼承自AbstractAirConditioner
VertableAirConditionerB-真實的空調層，繼承自AbstractAirConditioner
呼叫程式碼
命令列的結果
優缺點
優點：
1、實現了抽象和實現的分離
2、擁有更好的擴充套件性
3、可以動態的切換實現
缺點：
1、增加了系統的設計複雜程度
2、程式碼的可讀性差
橋接模式和適配模式的區別
大家有沒有發現這個我之前寫過的介面卡的解析 有點類似，我們來說明比較一下這個2個模式的區別
相同點：
橋接模式和介面卡模式都是讓兩個介面配合的工作
不同點：
橋接模式：把實現和抽象都分離開了，可以讓兩者的介面可以不一樣。主要的目的是把他們分離開了。橋接模式是先有橋在有2端的介面，這個就好像，我們控制空調的一些指令，他就想一個橋一樣，把我們一些通過遙控器傳遞給給空調，讓空調工作。
介面卡模式：介面卡模式是，先有2端的東西以後，為了讓2端的東西更好的相容，才有的介面卡。就好像我們的國家電網，和我們平常使用的電器裝置，他們是已經存在的2個介面，我們只是在中間做了一個轉換。讓他們配合著一起工作。
總結
如果有寫的不正確或者侵權的，希望大家給我提出來，我會及時修改。謝謝大家。