Design Patterns in ActionScript–Adapter

Our company is building a new project recently. This project is about simulated flight. The total solution will include the software module and hardware module. Unfortunately, our company just a software company, we don’t have the ability to design the hardware. So, our company wants to buy the hardware solution from other company, we only need to work out the software.

 

The software part looks like just a piece of cake to us. So, we quickly build a team to handle this task.

After many and many overtime, the team has finished the software module. And all the operation with hardware is reserved as an interface.

At the same time, our boss has met some hardware suppliers and decided to make a deal with one of them.

Sooner after the deal, we receive the hardware driver library. Things not always go that easy. This time, we found out that the hardware driver library is not fit for the interfaces reserved by our software.

This is a big problem. If we can’t fix it, we’ll only have two ways to go, one is rewriting our code to fit for the hardware driver library; the other is buying a new hardware solution. Eh, maybe we have the third choice, that’s we quit our jobs.

We were very depressed by this situation. But life still goes on. We check the driver library carefully, and we found that many functions can provide the function we need, but it has a different name. We can’t change the driver library. Does it mean that we need to change our code?

Obviously, we don’t want to do that, it’s not an easy job, further more, we’re all lazy guys. So, we need a tricky solution.

Genius programmers, what will you do if you’re in this situation?

Finally, a genius guy in our team gives a suggestion. This solution is much like building a bridge from the interfaces reserved in the software module and the functions provided by the driver library.

The solution is that, we build a new class to wrap driver library, and the new class will derived from the interfaces reserved by the software.

The original code is showing below.

1. public class Rocket {
2.  
3. private   var rocketLib : RocketLib ;
4.  
5. public   function Rocket (){
6.  
7. rocketLib = new   RocketLib () ;
8.  
9. }
10.  
11. public   function run () : void {
12. rocketLib . run () ;
13. }
14. }
15.  
16. public   class RocketDriver {
17.  
18. public   function run () : void {
19.  
20. trace ( " The Rocket Runs! " ) ;
21. }
22. }

As you see, the Rocket class is in our software module, and the RocketDriver class is in the library they provided. And the solution is as follows.

1. public class RocketLib {
2.  
3. private   var rocketDriver : RocketDriver ;
4.  
5. public   function RocketLib (){
6. rocketDriver = new   RocketDriver () ;
7. }
8.  
9. public   function run () : void {
10. rocketDriver . run () ;
11. }
12.  
13. }

Now, the software module doesn’t need to be changed. And everything goes well.

The UML diagram is as below.

Do you like this solution? Of course, this is a pattern named adapter pattern. The intent of this pattern is as follows.

Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.

–By GOF BOOK

Hope you have a sensitive feeling about this pattern now.

Demo | Download Full Project

Enjoy!