Analysis of Ruby design patterns-adapter)

Reprinted please indicate the source: http://blog.csdn.net/guolin_blog/article/details/9400153

This is a copy version of Java Design Pattern dialysis, which is specially provided for Ruby lovers. If you are not familiar with Ruby syntax, please refer:

Java Design Pattern Analysis-adapter) 

Early in the morning, your leader rushed to find you: "Fast, fast, urgent task! Chinajoy is about to begin recently. The boss asked for an intuitive way to view the number of online users of each server in our new game ."

You looked at the date, right! This is where we are about to start. It is clear that we have already started! How can this be done?

"It doesn't matter ." Your leader comforted you: "The function is actually very simple. All interfaces are provided. You just need to call it ."

Well, you accept it for a while. You have long been used to this sudden new demand.

Your leader gave you a detailed description of the requirements. Your game currently has three servers, one server has been open for a while, and the other two and the third servers are all new servers. The designed interface is very lightweight. You only need to call utility. online_player_count (fixnum): input the value corresponding to each server to obtain the number of online players in the corresponding server. For example, input 1 to server 2, input 2 to Server 3, and input 3 to Server 3. If you input a server that does not exist,-1 is returned. Then you just need to assemble the data into XML, and the specific display function is completed by your leader.

Well, it sounds like the feature is not very complicated. If it seems that it is still time to start the work now, you will immediately start typing the code.

First, define a playercount parent class used to count the number of online users. The Code is as follows:

class PlayerCountdef server_nameraise "You should override this method in subclass."enddef player_countraise "You should override this method in subclass."endend

Then define three statistical classes to inherit playercount, which correspond to three different servers, as shown below:

Class serverone <playercountdef SERVER_NAME "1 server" enddef player_countutility.online_player_count (1) endend

Class servertwo <playercountdef SERVER_NAME "two servers" enddef player_countutility.online_player_count (2) endend

Class serverthree <playercountdef SERVER_NAME "three servers" enddef player_countutility.online_player_count (3) endend

Define an xmlbuilder class to encapsulate data of different servers into XML format. The Code is as follows:

class XMLBuilderdef self.build_xml playerbuilder = ""builder << "<root>"builder << "<server>" << player.server_name << "</server>"builder << "<player_count>" << player.player_count.to_s << "</player_count>"builder << "</root>"endend

In this way, all the code is complete. To view the number of online players in a server, you only need to call:

XMLBuilder.build_xml(ServerOne.new)

To view the number of online gamers in Server 2, you only need to call:

XMLBuilder.build_xml(ServerTwo.new)

To view the number of online players in three servers, you only need to call:

XMLBuilder.build_xml(ServerThree.new)

Why? When you view the number of online players in a server, the returned value is always-1. It is normal to view both Server 2 and Server 3.

You have to call your leader: "I feel that the code I wrote is okay, but the number of online players in a server always returns-1. Why ?"

"Oh !" Your leader suddenly remembered, "This is my problem, and I have not explained it clearly before. Since our server has been open for a while, the function of querying the number of online players has long been available, using the serverfirst class. At that time, the utility. online_player_count () method was mainly used to repeat the query function of a server for the newly opened Server 2 and Server 3. In this case, you can use the adapter mode, which is used to solve the problem of incompatibility between interfaces ."

In fact, the use of the adapter mode is very simple, the core idea is that as long as two incompatible interfaces can be normally connected. In the above Code, playercount is used in xmlbuilder to assemble XML, while serverfirst does not inherit playercount. In this case, an adapter class is required to build a bridge between xmlbuilder and serverfirst, serverone will undoubtedly act as the adapter class. Modify the serverone Code as follows:

Class serverone <playercountdef initialize @ serverfirst = serverfirst. newenddef SERVER_NAME "one server" enddef player_count@serverFirst.online _ player_countendend

Through serverone adaptation, the interaction between xmlbuilder and serverfirst is successful! We don't even need to know the serverfirst class when using it. We just need to create a serverone instance.

It is worth noting that the adapter mode is not the one that makes the architecture more reasonable. More often, it is only used as a fireman, it helps solve interface mismatch problems caused by unreasonable preliminary architecture design. A better way is to try to consider the possible situations in the future during the design. Do not learn from your leader on this issue.

Adapter: converts an interface of a class to another interface that the customer wants. The adapter mode allows the classes that cannot work together due to interface incompatibility to work together.