Pattern Decoratore nei modelli di primo disegno della testa

2

Sto cercando di insegnarmi alcuni schemi di progettazione utilizzando un libro che mi è stato consigliato, Modelli di primo modello di testa . Sono arrivato al capitolo sul pattern Decorator, e anche se capisco lo scopo, sono un po 'confuso sul suo layout.

Ecco il loro UML di base del pattern Decorator: Imgur (Ci scusiamo per il collegamento, ma SE non mi permetterà di caricare una foto qui per qualche motivo)

Ecco come hanno scritto il codice:

public abstract class Component {
    String description = "Unknown Description";

    public String getDescription() {
        return description;
    }

    public abstract double cost();
}

public class ConcreteComponent extends Component {
    public ConcreteComponent() {
        description = "I am a concrete component";
    }

    public double cost() {
        return 1.99;
    }
}

public abstract class Decorator extends Component {
    public abstract String getDescription();
}

public class ConcreteDecorator extends Decorator {
    Component component;

    public ConcreteDecorator(Component component) {
        this.component = component;
    }

    public String getDescription() {
        return component.getDescription() + " with a decorator";
    }

    public double cost() {
        return .20 + component.cost();
    }
}

La mia domanda è, qual è la necessità di un corso di Decorator in questa situazione? Perché non lasciare getDescription () astratto e lasciare che ConcreteComponents e ConcreteDecorators lo implementino nel modo in cui hanno bisogno?

Come follow-up, ci sono benefici effettivi nella creazione di una classe Decorator? Questo esempio non sembra coprire il motivo per cui è utile o come potrebbe essere utile.

    
posta comscis 02.01.2014 - 00:27
fonte

1 risposta

3

Con un Decorator puoi aumentare il codice che stai tagliando senza cambiarlo affatto . E in alcuni casi, nemmeno dover sapere cosa fa.

Il principio aperto / chiuso afferma che

software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

Quindi, se lo rendessi astratto, cosa succederebbe se dovessi modificare la descrizione nella tua implementazione concreta? Dovresti modificare la tua classe.

Sì, questo particolare esempio è un po 'forzato. Tuttavia, con questo modello, è possibile aggiungere decoratori che aumentano un messaggio (come nel disegno degli Stream) o fornire aspetti che sono ortogonali al processo (come la registrazione o la traccia) senza toccare o modificare il codice che il Decorator sta eseguendo il wrapping .

Inoltre, poiché un Decorator è un Component puoi aggiungere un secondo Decorator senza dover sapere che avvolge un Decorator . In altre parole, questo aiuta a mantenere i Decoratori separati l'uno dall'altro. Ciò porta a un codice che è sia disaccoppiato che coesivo.

    
risposta data 02.01.2014 - 00:36
fonte

Leggi altre domande sui tag