Clarifiction on Adapter Pattern!

[Tulsi Rai]

Hi All,
I would appreciate if you could clearify some of my doubts that I always battle with while reading patterns. Here's what I don't understand:

  
  Light.java
 
  public class Ligth{
     public void turnOn(){
         //turn on light here
     }
  }
 
  Button.java
 
  public class Button{
      private Light light;
 
      public Button(Light light){
          this.light = light;
      }
 
      public void press(){
          light.turnOn();
      }
  }

The above design suffers from high coupling which is, as shown in an exmple,solved by an Adapter pattern by decoupling Button from Light. And here's how it has been done.

  
   public interface Switchable{
        void turnOn();
   }
 
   public class LightAdapter implements Switchable{
        private Light light;
     
        public LightAdapter(Light light){
            this.light = light;
        }
       
        public void turnOn(){
            light.turnOn();
        }
   }

As shown in the above design, an interface and adapter class are created. my question here is why bother creating an interface? can't it be designed just by creating an adapter class like this:

  
public class LightAdapter{
        private Light light;
     
        public LightAdapter(Light light){
            this.light = light;
        }
       
        public void turnOn(){
            light.turnOn();
        }
   }
 

and then have Button class use the Adapter. didn't it help decoule Button from Light? could you please point out what's wrong with my approach of having just an Adapter class not an interface?
thanks.

[Warren Dew]

The reason for decoupling is that you might want to couple to something else eventually.

In particular, if you have a "Switchable" interface, you might eventually come up with something else that can be switched on and off - say, a "SpaceHeater". If you had the interface, you could have "SpaceHeater" implement "Switchable", and then you could use your same old Button class to control a space heater instead of a light, without having to go back and change the Button class.

In my opinion, you don't need the interface as long as you only have the light. It's at the point where you know you'll have two things - say, a light and a heater - that it becomes worthwhile to factor out a separate adapter interface.

[Ilja Preuss]

Well, there are some possible other reasons to prefer the decoupling:

- Testability: If you have a Switchable interface, you can test the switch using a mock implementation, which significantly simplifies testing. (In fact this a special case of Warren's argument: for testing, you often want to have a second implementation.)

- Reduced compile time dependencies: Without the interface, whenever you change the adapter, the Button needs to be recompiled. In fact this dependency is transitive, that is, Button also needs to be recompiled when you change Light (because then the adapter needs to be recompiled) etc. pp. This can easily lead to the situation that a large part of the whole system needs to be recompiled because of a small change in a single class. With the interface, this dependency is removed - only when the interface itself needs to be changed, Button needs to be recompiled.

This is not only important for compile times, but also for decoupling the release process of modules. In big systems, Button and Light might be in different modules with different rate of changes and therefore different release schedules.

[Tulsi Rai]

Thanks Ilja for the response.

Originally posted by Ilja Preuss:
Well, there are some possible other reasons to prefer the decoupling:]

Well, I understand the importance of decoupling but why do we need both interface and adapter class to decoule. why not just have the adapter class decouple.

- Reduced compile time dependencies: Without the interface, whenever you change the adapter, the Button needs to be recompiled.

again, why the Button needs to be recompiled so long as the methods used by Button do not change in Adapter class?
thanks.

[Stan James]

Adapters are often inserted into a system to minimize the impact of some change. Suppose we changed from VendorXLight to VendorYLight. If we had coded to VendorX APIs we'd have to change our buttons. If we had coded a LightAdapter adapter with MyPersonalLight interface and VendorX APIs we could build a new LightAdapter that uses VendorY APIs and not touch the button.

In real life, I hard coded a button to my own light (ok, contract data to data accessor.) I owned all the code, felt really happy. Then somebody insisted I use a new light from another source. I had to mod my buttons. This time I built an adapter just in case they found yet another new light. There are several ways to do this ... I was in PowerBuilder which didn't support interfaces, so I gutted my light and turned the old light into an adapter to the new light. Button did not change, but it was kinda ugly.

When do you use an Interface that will make insertion of an adapter easy later? When you think you need to protect yourself against possible change. It's silly to put an interface on every darned thing, and maybe costly when you don't have one in a change, and a sign of wisdom if you make exactly the right number of interfaces.

[Ilja Preuss]

Originally posted by t ray:
why the Button needs to be recompiled so long as the methods used by Button do not change in Adapter class?

Well, actually you are right - strictly speaking you wouldn't need to. But in reality, I don't know of a single compiler which would reliably detect this.

[steve souza]

In this example LightAdapter adds no real value and you might as well just have light implement the Swithcable interface directly (i.e. it adds no value and simply calls the Light methods). Then button should take a Switchable in the contstructor, not a Light. If you never envision having another Switchable type besides Light then creating a Switchable interface may be overkill.

[Maulin Vasavada]

Hi Stan James ,

I am planning to use the adapter in similar situation.

We are gonna use some Java based schedular but for now we don't have time to really see how a third party code works so what I am going to do is- create adapter to Schedular (by creating an interface/abs class) that can be easily changed afterwards to use a particular Scheduler and client code won't have to be changed (it might have to be recompiled but atleast interface definition won't change ...)

Thanks
Maulin