È un decoratore o un modello di strategia, o nessuno dei due?

Question

Ho la seguente interfaccia.

PowerSwitch.java

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

L'interfaccia sopra dovrebbe consistere di un insieme minimo di metodi che qualsiasi altra funzionalità possono essere derivati ​​da, per rendere il più semplice possibile aggiungere implementazioni PowerSwitch aggiuntivi.

vorrei aggiungere funzionalità all'interfaccia PowerSwitch in fase di esecuzione (cosa decoratori fare), creando una classe che detiene una composizione di un'istanza PowerSwitch e aggiunge nuovi metodi, come i due toggleOnOff() metodi sotto. In questo modo ho solo bisogno di implementare i due metodi di commutazione una volta e si applicherà a tutte le implementazioni PowerSwitch.

È considerata una buona/cattiva pratica? Se cattivo, qualche altro consiglio?

In realtà non è conforme al modello di decorazione in quanto aggiunge ulteriori metodi. È un modello di strategia o uno schema di composizione? O ha un altro nome di modello? Esiste un "decoratore di interfacce"?

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

Questa è una buona pratica nel caso di necessità di migliorare l'istanza PowerSwitch in fase di esecuzione. Vi consiglio di implementare l'interfaccia PowerSwitch nel decoratore. L'altro nome del pattern decorator è il pattern proxy.

È possibile definire i metodi estesi in un'altra interfaccia che estende l'interfaccia PowerSwitch. Ciò eviterà di dipendere dal decoratore quando saranno necessari questi metodi estesi.

L'estensione di una classe è una buona pratica quando è necessario migliorare o ridefinire un comportamento durante la compilazione.

Answer 2

Sarebbe davvero un decoratore se il decoratore implementasse anche l'interfaccia PowerSwitch. Lo definirei come aggregazione di oggetti.

Answer 3

Così com'è, qualsiasi codice che vuole utilizzare i toggleOnOff(int) o toggleOnOff() metodi avrà bisogno di un'istanza di PowerSwitchDecorator, non PowerSwitch. Questo tipo di sconfigge lo scopo di un decoratore che dovrebbe essere trasparente per il cliente.

Se si desidera che tutte le implementazioni abbiano questi metodi, è necessario includerle nell'interfaccia PowerSwitch.

Poi, come suggerisce @Ani, è possibile modificare quanto sopra PowerSwitchDecorator di estendere PowerSwitch modo da poter fare questo:

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

ora avete una variabile di tipo PowerSwitch con funzionalità 's il PowerSwitchDecorator.

MODIFICA: Si noti che è necessario utilizzare un modello stabilito solo se soddisfa le proprie esigenze. Puoi usare l'approccio che hai mostrato se funziona per te. Non è necessario calzare il corno in un modello specifico.

Che tipo di oggetto vuoi passare in giro? Vuoi metodi come questo nel tuo API:

void connect(PowerSwitch powerSwitch, Appliance appliance); 

o metodi come questo:

void connect(PowerSwitchDecorator powerSwitch, Appliance appliance); 

(mi dispiace, non sono molto buoni esempi)

Se si desidera che il primo, quindi tutti dovranno "decorare" manualmente il loro PowerSwitch solo per ottenere un paio di metodi di convenienza. Potrebbe essere conveniente per te ora, ma penso che sarà scomodo per gli utenti del tuo codice e probabilmente non si preoccuperanno di farlo. Se si desidera quest'ultimo, è necessario utilizzare il tipo PowerSwitchDecorator nelle firme dei metodi, il che tende a significare che si tratta sempre di PowerSwitchDecorator s e non grezzo PowerSwitch es.

Answer 4

Non è uno dei motivi.

Un decoratore ha l'intenzione di racchiudere un oggetto ed estendere la funzionalità già esistente rendendo l'interfaccia trasparente per il client. Un BufferedInputstream è un esempio. Si noti che Decorator deve implementare la stessa interfaccia del tipo che si sta avvolgendo.

//Let Type be the interface that both the Decorator and DecoratedClass implements 
Type yourInstance = new Decorator(new DecoratedClass()); 

Nota la differenza dal Proxy-modello, dove l'intento principale è quello di controllare l'accesso ad un oggetto, non necessariamente avvolgendo un altro oggetto. In questo caso, consentirebbe al proxy di implementare la stessa interfaccia.

Answer 5

Diversi motivi spesso sembrano simili, la differenza sta nell'intento del loro utilizzo. Ecco una discussione più generale su questo argomento: When and How Strategy pattern can be applied instead of decorator pattern?

Con il tuo codice, non c'è ancora alcuna differenza reale. Sembra una strategia, poiché PowerSwitchDecorator sta semplicemente delegando il lavoro (cioè l'algoritmo) a un PowerSwitch. Se questa è la tua intenzione e ci sono alterni PowerSwitch che si alternano in modi diversi, lo schema di strategia è la tua scelta.

Se invece si dispone di un set di pulsanti PowerSwitch, ognuno di questi migliora la commutazione in un modo leggermente (decorando la commutazione) e questi PowerSwitch possono essere nidificati, quindi si sta implementando un decoratore. Come già detto, in questo caso è necessario che i decoratori facciano parte della gerarchia di tipi.

Answer 6

Direi che non è uno dei motivi.

motivo decoratore

Il pattern decorator viene utilizzato per estendere il comportamento di un'implementazione esistente. Prendi una finestra grafica come esempio, potresti avere una finestra con barre di scorrimento. Allora si può avere una classe come

public class ScrollBarsWindow : Window 
{ 
    private Window windowToDecorate; 
    public ScrollBarsWindow(Window windowToDecorate) 
    { 
     this.windowToDecorate = windowToDecorate; 
    } 

    public void Draw() 
    { 
     windowToDecorate.Draw(); 
     DrawScrollBars(); 
    } 

    public void DrawScrollBars() 
    { Draw the scroll bars } 
} 

Il modello di strategia

Il modello di strategia è usato per fare cose diverse a seconda della strategia scelta. Diciamo che stai facendo un caffè.La si potrebbe avere qualcosa di simile:

public interface IMakeCoffeeStrategy 
{ 
    public Coffee MakeCoffee(); 
} 

public class CappuccinoStrategy : IMakeCoffeeStrategy 
{ 
    public Coffee MakeCoffee { make your cappuccion } 
} 

public class LatteStrategy : IMakeCoffeeStrategy 
{ 
    public Coffee MakeCoffee { make your latte } 
} 

public class Context 
{ 
    private IMakeCoffeeStrategy strategy; 
    public Context(IMakeCoffeeStrategy strategy) 
    { 
     this.strategy = strategy; 
    } 

    public Coffee MakeSomeCoffee() 
    { 
     return strategy.MakeCoffee(); 
    } 
} 

e utilizzarlo come

public class MyCoffeeMachine 
{ 
    public Coffee MakeCoffee(CoffeeType coffeeType) 
    { 
     if(coffeeType == CoffeeType.Latte) 
      return new Context(new LatteStrategy()).MakeSomeCoffee(); 
     else if(coffeeType == CoffeeType.Cappuccino) 
      return new Context(new CappuccinoStrategy()).MakeSomeCoffee(); 

     ... 
    } 
} 

Leggere i seguenti link per ulteriori informazioni:

• Strategy
• Decorator

Answer 7

La tua classe PowerSwitchDecorator non è decoratore. L'implementazione è vicino a Strategy_pattern anche se i comandi assomigliano Command_pattern

In Decorator modello, Decorator in realtà implementa l'interfaccia (cioè Component) e la vostra classe non sta facendo lo stesso.

Dai un'occhiata alla diagramma delle classi

Nel diagramma sopra, Component è un'interfaccia. Decorator implementa l'interfaccia Component e contiene l'interfaccia con Composition. Guarda la variabile membro - component.

riferirsi a queste domande per una migliore comprensione:

Decorator Pattern for IO

Real World Example of the Strategy Pattern