設計模式-介面卡模式(Go語言描述)
在上一篇部落格設計模式-策略模式(Go語言描述)中我們用最簡單的程式碼用go語言描述了設計模式中的策略模式,用最簡單的例項來描述相信可以讓初學者可以很輕鬆的掌握各種設計模式。繼上篇部落格,我們接著用同樣簡單的程式碼來了解一下介面卡模式。
介面卡模式介紹
說起介面卡模式,相信很多做android的同學第一印象就是AdapterView的Adapter,那它是幹嘛用的呢?為什麼要叫adapter呢?要了解這個問題,我們首先來看看介面卡模式的定義:
將一個類的介面轉換成客戶希望的另外一個介面。介面卡模式使得原本由於介面不相容而不能一起工作的那些類可以一起工作。——Gang of Four
恩,看起來好像有點迷糊,舉個例子吧:
我電腦的電源是三個插頭(也就是有地線)的那種,不知道為啥學校的插座都是兩個插孔的,哎呀,這可咋辦啊!同學建議我們買個轉換器,這種轉換器有三個插孔,我的電源可以插進去,同時它還有兩個插頭,可以插進學校的插座裡,嘿嘿,同學真聰明,這麼容易的就解決了我的問題。
在上面的例子裡,那個轉換器也可以叫做介面卡,我們現在要說的介面卡模式靈感就是來自上述所述的實際生活中遇到的問題。那在我們程式設計中會遇到什麼樣的問題呢? 再來看個例子:
應老師的要求,我們現在需要做一個音樂播放器,現在我算是知道一點面向物件的原則了,所以我首先設計了一個介面,這個介面有一個playMusic的方法,接著我很輕鬆的利用這個介面設計出了一個音樂播放器,音樂控制器通過呼叫playMusic可以完美的播放任何音樂,嘖嘖嘖,高興中…老師對我的音樂播放器也很滿意,不過他又提出了新的需求,讓我的音樂播放器也可以播放遊戲的聲音,並給了我一個播放遊戲聲音的類,這個類也很簡單,只有一個playSound方法,雖然很簡單,但是現在我困惑了,因為我設計的音樂控制器只認識playMusic而不認識playSound,難道我要重新設計我的音樂控制器嗎?正當我苦惱的時候,同學出現在了我身後,輕聲的告訴我:“介面卡模式可以完美的解決你的問題,你只需要寫一個Adapter實現你的音樂播放介面,在這個Adapter的playMusic中去呼叫遊戲聲音播放器的playSound方法就可以了。”聽了同學的話,我突然恍然大悟,原來這就是介面卡模式!
好了,通過上面的三個小段子,相信大家對介面卡模式應該了有了大概的認識,下面還是用一張結構圖來清晰的描述一下什麼是介面卡模式吧。
通過上面的圖我們也可以看出來,介面卡要做的事情就是讓我們寫的野實現適配到系統需要的標準實現上。下面我們迅速進去程式碼模式,讓程式碼告訴我們介面卡模式張啥樣!
程式碼實現
程式碼實現環節,我們還是用上面那個音樂播放器的例子,首先設計一個音樂播放的介面:
package player
type Player interface {
PlayMusic()
}
這個介面只有一個方法PlayMusic
,系統通過呼叫PlayMusic
這個方法達到播放音樂的目的。 在來看看我們播放音樂的實現。
package player
import "fmt"
type MusicPlayer struct {
Src string
}
func (p MusicPlayer) PlayMusic() {
fmt.Println("play music: " + p.Src)
}
MusicPlayer
有一個方法是PlayMusic()
,所以它實現了Player
介面,來讓我們的音樂播放器播放器來吧,
package main
import . "./player"
func main() {
var player Player = MusicPlayer {Src:"music.mp3"}
play(player)
}
func play(player Player) {
player.PlayMusic()
}
程式碼也超級簡單,一個play
方法去呼叫了Player
的實現的PlayMusic
方法。來看看結果,
現在我們的音樂播放器可以播放歌曲了,只需要給出一個歌曲的路徑就ok,不過現在我們還需要播放遊戲聲音,並且給了我們一個這樣的實現。
package player
import "fmt"
type GameSoundPlayer struct {
Src string
}
func (p GameSoundPlayer) PlaySound() {
fmt.Println("play sound: " + p.Src)
}
GameSoundPlayer
也是有一個Src
屬性,也有一個方法,不過這個方法叫PlaySound
,並不是我們需要的PlayMusic
,那可咋辦呢?別忘了咱們的play
方法
需要的是一個Player
的實現,並自動呼叫了PlayMusic
方法,下面本節的主角-GameSoundAdapter
出場。
package player
type GameSoundAdapter struct {
SoundPlayer GameSoundPlayer
}
func (p GameSoundAdapter) PlayMusic() {
p.SoundPlayer.PlaySound()
}
GameSoundAdapter
有一個GameSoundPlayer
型別的屬性,它就是我們上面的那個遊戲聲音播放器,GameSoundPlayer
還有一個方法名字叫PlayMusic
,所以GameSoundPlayer
實現了Player
介面,我們可以把它用於player
方法中,在PlayMusic
中我們是呼叫的GameSoundPlayer
的PlaySound
來播放聲音的。
來看看我們這個介面卡適配的咋樣,
package main
import . "./player"
func main() {
gameSound := GameSoundPlayer {Src:"game.mid"}
gameAdapter := GameSoundAdapter {SoundPlayer:gameSound}
play(gameAdapter)
}
func play(player Player) {
player.PlayMusic()
}
看main函式中,首先我們還是有一個GameSoundPlayer
型別的變數,然後將它賦值給了GameSoundAdapter
的SoundPlayer
屬性,下面呼叫GameSoundAdapter
的PlayMusic
方法,就可以間接的呼叫GameSoundPlayer
的PlaySound
方法了,這樣我們就輕鬆的將GameSoundPlayer
適配到了Player
。
來看看結果:
整體來看我們的程式碼還是很簡單,不過簡單的程式碼已經將介面卡模式講解的很清楚了,那最後我們來思考一個問題,介面卡模式體現了哪些面向物件的設計原則呢?針對介面程式設計有木有? 開閉原則有木有?
相關推薦
設計模式-介面卡模式(Go語言描述)
在上一篇部落格設計模式-策略模式(Go語言描述)中我們用最簡單的程式碼用go語言描述了設計模式中的策略模式,用最簡單的例項來描述相信可以讓初學者可以很輕鬆的掌握各種設計模式。繼上篇部落格,我們接著用同樣簡單的程式碼來了解一下介面卡模式。 介面卡模式介紹
設計模式-模板方法模式(Go語言描述)
這篇文章我們還是繼續我們的設計模式系列, 今天我們帶來的一個全新的設計模式在實際開發中大家肯定都遇到過, 可能大家只是不知道它叫模板方法模式而已, 今天我們就來詳細的說一下什麼是模板方法模式,已經該模式如何運用. 至於什麼是模板方法模式, 我們還是老規矩, 先來個定義, 然後上張類圖
設計模式-代理模式(Go語言描述)
大家好, 我是大帥哥,由於最近又變帥了, 所以我決定由我的代理人小帥哥來寫這篇部落格,不過內容可以放心,還是由我來完成,小帥哥的活就是將我的內容替我發出來罷了。 &_& 還是進入正題吧, 今天這篇部落格我們繼續來學習設計模式, 在學習了上面幾個設計模式之後大家有沒有發
設計模式-建造者模式(Go語言描述)
在上一篇部落格設計模式-裝飾者模式中我們介紹瞭如何在golang中實現裝飾者模式,今天我們接著上篇部落格繼續設計模式系列文章,今天還是來看一個簡單的設計模式-建造者模式。 介紹 相信做過android的同學對建造者模式還是比較熟悉的, 一定用過開源的圖片載入框架ImageLoad
設計模式-裝飾者模式(Go語言描述)
什麼是裝飾者模式 好久沒有更新設計模式系列的部落格了, 今天我們來聊一聊裝飾者模式, 用過java的同學肯定對裝飾者模式非常熟悉,就算你不知道什麼是裝飾者模式這概念, 你也一定在程式碼中經常用到這個模式,為什麼這麼說呢? 大家都用過java中的流吧, 我們可以這樣寫: new B
設計模式-命令模式(Go語言描述)
在上一篇部落格設計模式-單例模式(Go語言描述)中我們介紹了在golang中如何去實現單例模式,在文章的最後我們也介紹到了golang獨有的一種實現單例的方式-sync.Once.Do(),可以讓golang輕鬆的實現可以應對併發請求的單利.今天我們繼續探索設計模式,來介紹一下命令模式的
設計模式-單例模式(Go語言描述)
這篇部落格我們繼續來看設計模式,今天帶來的是一個最簡單而且最常用的模式-單例模式。那什麼是單例模式呢?相信大家最它最熟悉不過了,那我們就來快速的瞭解一下它的定義。 保證一個類僅有一個例項,並提供一個訪問它的全域性訪問點。 這個解釋足夠簡單。說白了就是
23種設計模式---介面卡模式
package com.bjpowernode.demo03; import java.io.FileInputStream; import java.io.FileOutputStream; import java.io.IOException; import java.io.Inpu
android設計模式——介面卡模式
定義:介面卡模式就是把一個類的介面變換成客戶端所期待的另一種介面,從而使原本介面不匹配的而無法工作的兩個類能夠一起工作 使用場景: 系統要使用現有的類,但此類的介面不符合系統的需要,即介面不相容。 想要建立一個可以重複使用的類,用於與一些彼此之
設計模式——介面卡模式和外觀模式
介面卡模式和外觀模式 本文將分別介紹介面卡模式和外觀模式。 1、介面卡模式 1.1、定義 介面卡模式 將一個類的介面,轉換成客戶期望的另一個介面。介面卡讓原本介面不相容的類可以合作無間。 介面卡模式的定義非常易懂,就是將一個介面轉換成另一個介面,這樣一來就實現了介面的
設計模式 --- 介面卡模式
1.定義 介面卡模式把一個類的介面變換成客戶端所期待的另一種介面,從而使原本因介面不匹配而無法在一起工作的兩個類能夠在一起工作。 2.使用場景 1.系統需要使用現有的類,而此類的介面不符合系統的要求,即介面不相容。 2.想要建立一個可以重複使用的類,用於與一些彼此之
設計模式-介面卡模式(Adapter)
概述 定義 : 將一個類的介面轉換成客戶期望的另一個介面 使原本不相容的類可以一起工作 型別 : 結構型 適用場景 已經存在的類, 它的方法和需求不匹配時(方法結果相同或相似) 不是軟體設計階段考慮的設計模式, 而是隨著軟體
Java設計模式 介面卡模式
轉載自:https://www.cnblogs.com/V1haoge/p/6479118.html 感謝原作者! 介面卡就是一種適配中介軟體,它存在於不匹配的二者之間,用於連線二者,將不匹配變得匹配,簡單點理解就是平常所見的轉接頭,轉換器之類的存在。 介面卡有以下三
設計模式--------介面卡模式
介面卡模式有三個重要的成員:Target(目標介面),Adaptee(源角色),Adapter(介面卡)。 Target(目標介面): 所要轉換的期待的介面。(系
移動開發之設計模式-介面卡模式(IOS&Android)
資源 完全參照 組合模式|菜鳥教程 ,但不包括IOS程式碼 介面卡模式 介面卡模式(Adapter Pattern)是作為兩個不相容的介面之間的橋樑。這種型別的設計模式屬於結構型模式,它結合了兩個獨立介面的功能。 這種模式涉及到一個單一的類,該類負責加入獨立的或不相容的介面功能。
【IO】- IO 體系中的設計模式-介面卡模式
前言 之前的部落格說到了介面卡模式的概念和UML類圖,這次來聊下IO中的介面卡模式。 正文 IO流體系介紹 InputStreamReader 和OutputStreamWriter 類分別繼承了Reader和Writer 介面,但是
設計模式在專案架構中的最佳實踐 -- 生成器模式介面卡模式
設計模式在專案架構中的最佳實踐 – 生成器模式/介面卡模式 一年多來,做了幾個專案,雖然沒有什麼技術和業務難度,但是也不能白白浪費了自己一年的光景,除了技術也業務外,總有一些知識值得我們去總結和學習; 這麼些年埋頭於苦幹,很少抽出時間來整理提高自己的綜合
設計模式-介面卡模式
介面卡模式也是常用到的設計模式,算是一種補償模式,用來在系統後期擴充套件修改時使用,在詳細設計階段不適合使用;會先簡單介紹下介面卡模式,以及它的幾個部分,最後通過一個例子來簡單演示下; 1.定義 將一個類的介面轉換為希望的另一個介面,介面卡模式使得原來由
php設計模式 -- 介面卡模式
1.介面卡模式: 能夠將截然不同的函式介面封裝成統一的API 2.實際應用舉例,PHP的資料庫操作有mysql, mysqli, pdo3種。能夠用介面卡模式統一成一致。相似的場景還有cache介面卡,就是將memcache,redis,file,apc等不同的快取函式統一成一致的&nbs
java23種設計模式-介面卡模式
定義 介面卡模式是把一個類的介面轉換成客戶所期望的另一種介面,從而使原本不匹配而無法在一起工作的兩個類可以一起工作。 UML 角色 Target: 符合客戶端期望的介面。 Adaptee: 需要被適配的類。此類包含了客戶端想要實現的大部分功能,但並不能完