Design mode-Adapter mode (Go language description)

This is a creation in Article, where the information may have evolved or changed.

In the previous blog design mode-strategy mode (Go language description) We use the simplest code in the Go language to describe the design pattern of the strategy model, with the simplest examples to describe the belief can make it easy for beginners to master a variety of design patterns. Following the previous blog, we then use the same simple code to understand the adapter pattern.

Adapter Mode Introduction

Speaking of the adapter mode, I believe that many of the students do Android first impression is Adapterview adapter, then it is why use it? Why do you call adapter? To understand this problem, let's look at the definition of the adapter pattern first:

Transforms the interface of one class into another interface that the customer wants. The adapter mode makes it possible for those classes that would otherwise not work together because of incompatible interfaces to work together. --gang of Four

Well, it looks like a little hazy, for example:

My computer's power is three plugs (that is, there is ground) the kind, do not know why the school sockets are two jacks, gee, this can do AH! Students suggest that we buy a converter, this converter has three jacks, my power can be plugged in, and it also has two plugs, you can plug into the school socket, hey, classmate really smart, so easy to solve my problem.

In the example above, the converter can also be called an adapter, and the adapter pattern we're going to say now is inspired by the real-life problems described above. What kind of problems do we encounter in our program design? Let's look at an example:

At the teacher's request, we now need to make a music player, now I know a bit of object-oriented principle, so I first designed an interface, this interface has a Playmusic method, and then I easily use this interface to design a music player, Music controller by calling Playmusic can perfectly play any music, Tut tut, happy in ... The teacher is also very satisfied with my music player, but he put forward the new demand, let my music player also can play the game sound, and gave me a play game sound class, this class is also very simple, only a PlaySound method, although very simple, but now I confused, Because I designed a music controller that only knows Playmusic and doesn't know PlaySound, do I have to redesign my music controller? Just when I was distressed, the classmate appeared behind me, Softly told me: "Adapter mode can perfectly solve your problem, you only need to write a adapter implementation of your music playback interface, In this adapter Playmusic to call the game sound player PlaySound method is possible. Listen to the classmate's words, I suddenly realized that this is the adapter mode!

Well, through the above three little pieces, I believe that the adapter mode should have a general understanding of the following or a structure diagram to clearly describe what is the adapter mode it.

As we can see from the above diagram, the thing that the adapter is going to do is to adapt the wild implementations that we write to the standard implementations required by the system. Below we quickly go into code mode, let the code tell us the adapter pattern Zhang what kind!

Code implementation

Code implementation, we still use the above example of the music player, first design a music playback interface:

package playertypeinterface {    PlayMusic()}

This interface has only one method PlayMusic , the system by calling PlayMusic this method to achieve the purpose of playing music. Take a look at the implementation of the music we play.

package playerimport"fmt"typestruct {    string}func (p MusicPlayer) PlayMusic() {    fmt.Println("play music: " + p.Src)}

MusicPlayerOne way is PlayMusic() , so it implements the Player interface to let our music player player come in,

package mainimport"./player"func main() {    var player Player = MusicPlayer {Src:"music.mp3"}    play(player)}func play(player Player) {    player.PlayMusic()}

The code is also super simple, a play way to invoke the Player implementation of the PlayMusic method. Look at the results,

Now our music player can play the song, just give a path to the song is OK, but now we need to play the game sound, and give us one such implementation.

package playerimport"fmt"typestruct {    string}func (p GameSoundPlayer) PlaySound() {    fmt.Println("play sound: " + p.Src)}

GameSoundPlayerThere is also a Src property, there is a method, but this method PlaySound is called, not what we need PlayMusic , what can we do? Don't forget the way we do it. play
What is needed is an Player implementation, and the method is automatically called PlayMusic , the protagonist of this section below- GameSoundAdapter appearances.

package playertypestruct {    SoundPlayer GameSoundPlayer}func (p GameSoundAdapter) PlayMusic() {    p.SoundPlayer.PlaySound()}

GameSoundAdapterThere is a GameSoundPlayer type of property, it is the game sound player above us, there is GameSoundPlayer a method name PlayMusic , so GameSoundPlayer implement the Player interface, we can use it in the player method, in which PlayMusic we are called GameSoundPlayer PlaySoundto play the sound.
Let's see how this adapter fits,

package mainimport"./player"func main() {    gameSound := GameSoundPlayer {Src:"game.mid"}    gameAdapter := GameSoundAdapter {SoundPlayer:gameSound}    play(gameAdapter)}func play(player Player) {    player.PlayMusic()}

Look at the main function, first we still have a GameSoundPlayer type of variable, and then assign it to GameSoundAdapter the SoundPlayer property, the method called below GameSoundAdapter , PlayMusic you can indirectly call GameSoundPlayer the PlaySound method, so we will be easy GameSoundPlayer to fit into the Player.
Let's look at the results:

Overall our code is still very simple, but the simple code has explained the adapter mode is very clear, then finally we think of a problem, the adapter pattern embodies what object-oriented design principles? Is there any wood for the interface programming ? The principle of opening and shutting has wood?

OK, adapter mode here we are, and finally the example code for the article download: http://download.csdn.net/detail/qibin0506/9420484