Design mode-Adapter mode (Go language description)

In the previous blog design pattern-strategy mode (Go language description) We used the simplest code to describe the strategy pattern in the design pattern with the go language, using the simplest examples to describe the narrative belief that people who have just started learning can easily master various 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 very many of the students to do Android first impression is Adapterview adapter, then it is why use it? Why do you call adapter? To understand this problem. Let's start by looking at the definition of the adapter pattern:

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. --gang of Four

Well, it looks like a little confusing, 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 we buy a converter, this converter has three jacks, my power can plug in, the same time it also has two plugs, can plug into the school socket, hey, classmate really smart, so easy to conquer my problem.

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

At the teacher's request, we now need to make a music player, now I know a little object-oriented principle, so I first designed an interface. This interface has a Playmusic method, then I am very easy to use this interface to design a music player, music controller by calling Playmusic can play perfectly whatever music. Tut-tut, happy in ... The teacher is also very comfortable with my music player. It's just that he's made a new demand for my music player to be able to play the game sounds. and gave me a class to play the game sound. This class is also very easy. There is only one PlaySound method, although very easy, but now I am confused, because I designed the music controller only know Playmusic and do not know PlaySound, do I want to design my music controller again? Just when I was distressed, the classmate out of my back now, Softly told me: "Adapter mode can perfectly solve your problem, you only need to write a adapter to achieve your music playback interface, In this adapter Playmusic to call the game sound player PlaySound method can be.

"Listen to the words of the classmates." It suddenly dawned on me. This is the adapter mode!

All right. 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 clear description of what is the adapter mode bar.

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

Code implementation

Code implementation, we still use the example of the music player above, 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)}

MusicPlayerThere is one way PlayMusic() to do this, so it implements the Player interface. Come on, let's have our music player player come on,

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 is able to play songs. Just need to give a path to a song OK, but now we still need to play the game sound. And it gives us one of these implementations.

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, just this method is called PlaySound . It is 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 called on its own initiative PlayMusic , the protagonist of the following section- 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. GameSoundPlayerAnother method name is called PlayMusic . So the GameSoundPlayer Player interface is implemented, and we are able to use it in the player method, in which PlayMusic we are calling GameSoundPlayer PlaySound to 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. By using a GameSoundAdapter downward PlayMusic method, you can call GameSoundPlayer the method indirectly PlaySound , so that we will be able to easily GameSoundPlayer fit into the Player .
Let's look at the results:

Overall our code is very easy, but the simple code has already 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?

All right. Adapter mode We're going to talk about this, and finally the case code. Download: http://download.csdn.net/detail/qibin0506/9420484

Design mode-Adapter mode (Go language description)