Is this a decorator or a strategy pattern, or neither of the two?

Question

I have the following interface.

PowerSwitch.java

public interface PowerSwitch {
    public boolean powerOn();
    public boolean powerOff();
    public boolean isPowerOn();
}

The above interface should consist of the minimum set of methods which any other functionality can be derived from, to make it as easy as possible to add additional PowerSwitch implementations.

I would like to add functionality to the PowerSwitch interface at run-time (what decorators do), by creating a class which holds a composition of a PowerSwitch instance and adds new methods, like the two toggleOnOff() methods below. That way i only need to implement the two toggle methods once and it will apply to all PowerSwitch implementations.

Is this considered as a good/bad practice? If bad, any other recommendations?

It doesn't really comply to the decorator-pattern as it adds extra methods. Is it a strategy pattern, or a composition pattern? Or does it have another pattern name? Is there such thing as an "interface decorator"?

PowerSwitchDecorator.java

public class PowerSwitchDecorator {
    private PowerSwitch ps;

    public PowerSwitchDecorator(PowerSwitch ps) {
        this.ps = ps;
    }

    public void toggleOnOff(int millis) throws InterruptedException{
        powerOn();
        Thread.sleep(millis);
        powerOff();
    }

    public void toggleOnOff(){
    powerOn();
    powerOff();
    }

    public boolean powerOn() {
        return ps.powerOn();
    }

    public boolean powerOff() {
        return ps.powerOff();
    }

    public boolean isPowerOn() {
        return ps.isPowerOn();
    }
}

Answer 1

As it is, any code that wants to use the toggleOnOff(int) or toggleOnOff() methods is going to need an instance of PowerSwitchDecorator, not PowerSwitch. This kind of defeats the purpose of a decorator which should be transparent to the client.

If you want all implementations to have these methods, you should include them in the PowerSwitch interface.

Then, as @Ani suggests, you could modify the above PowerSwitchDecorator to extend PowerSwitch so you can do this:

PowerSwitch switch = new PowerSwitchDecorator(new ConcretePowerSwitch());
switch.toggleOnOff();

Now you have a variable of type PowerSwitch with the PowerSwitchDecorator's capabilities.

EDIT: Note that you should only use an established pattern if it meets your needs. You can use the approach you have shown if it works for you. No need to shoe-horn it into a specific pattern.

What type of object do you want to pass around though? Do you want methods like this in your API:

void connect(PowerSwitch powerSwitch, Appliance appliance);

Or methods like this:

void connect(PowerSwitchDecorator powerSwitch, Appliance appliance);

(sorry, they're not very good examples)

If you want the former, then everyone is going to have to manually 'decorate' their PowerSwitch just to get a couple of convenience methods. It may be convenient for you now but I think that it will be inconvenient for users of your code and they will probably not bother with it. If you want the latter, you have to use the type PowerSwitchDecorator in your method signatures, which tends to mean that you always deal with PowerSwitchDecorators and not raw PowerSwitches.

Answer 2

That's a good practice in the case you need to enhance your PowerSwitch instance at runtime. I recommend you to implement The PowerSwitch interface in the decorator. The other name of decorator pattern is proxy pattern.

You can define the extended methods in another interface which extends your PowerSwitch interface. That will avoid having a dependency on the decorator when these extended methods are needed to be called.

Extending a class is a good practice when you need to enhance or redefine a behavior at compilation.