Design mode-Adapter mode (Go language description)

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 the code mode, let the code tell us what the adapter pattern is like. Code Implementation

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

Package player

type player interface {
    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 player
Import "FMT"

type musicplayer struct {
    Src string
}

func (P musicplayer) Playmusic () {
    FMT. Println ("Play Music:" + p.src)
}

Musicplayer has a method is Playmusic (), so it implements the player interface, to let our music player player come on,

Package main
Import. "./player"

func Main () {
    var player player = Musicplayer {Src: "Music.mp3"}
    play (player)
}

func Play (player player) {
    player. Playmusic ()
}

The code is super simple, and a play method invokes the Playmusic method of the player's implementation. 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 player
Import "FMT"

type gamesoundplayer struct {
    Src string
}

func (p Gamesoundplayer) PlaySound () {
    fmt. Println ("Play Sound:" + p.src)
}

Gamesoundplayer also has a src attribute, there is a method, but this method is called PlaySound, not we need playmusic, that can do. Don't forget our play method.
What is needed is an implementation of the player, and automatically calls the Playmusic method, the protagonist of this section-gamesoundadapter appearances.

Package player

type gamesoundadapter struct {
    soundplayer gamesoundplayer
}

func (P gamesoundadapter) Playmusic () {
    p.soundplayer.playsound ()
}

Gamesoundadapter has a Gamesoundplayer type of property, it is the game sound player above us, gamesoundplayer there is a method named Playmusic, So Gamesoundplayer implements the player interface, which we can use for the player method, and in Playmusic we call the Gamesoundplayer PlaySound to play the sound.
Let's see how this adapter fits,

Package main
Import. "./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 variable of type Gamesoundplayer, and then assign it to the Gamesoundadapter SoundPlayer property, the following call Gamesoundadapter Playmusic method , it is possible to call Gamesoundplayer's PlaySound method indirectly, so that we can easily fit the Gamesoundplayer to the player.
Let's look at the results:

Overall our code is still very simple, but the simple code has already explained the adapter pattern very clearly, then finally we think of a problem, the adapter pattern embodies what object-oriented design principles. for interface Programming there are wood. The principle of opening and shutting has wood.

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