Perché abbiamo bisogno dell'interfaccia Decorator?

Question

Perché abbiamo bisogno dell'interfaccia Decorator?

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

1

Passando attraverso Decorator Pattern da Wikipedia 1 e leggendo il pattern di Head First Book. Una cosa che mi ha colpito e che manca a entrambe le fonti potrebbe essermi sfuggita.

Perché esattamente abbiamo bisogno di un'interfaccia Decorator?

È perché abbiamo bisogno di mettere tutti i Decoratori in cemento sotto l'ombrello categorico.

Supponiamo che se avessimo solo pochi decoratori (< 5), non li possiamo semplicemente sublocassare direttamente da Component Interface. Termini da wikipedia UML Quindi Decorator memorizzerà il riferimento di Component Interface Type e chiamerà il comportamento direttamente della Concrete Component dopo aver aggiunto qualcosa in più. Questa è la stessa cosa degli esempi del Primo libro.

Un altro motivo per cui posso pensare a Putting a Decorator Interface è avere il supporto di runtime per aggiungere questi decoratori attraverso Factory. Questa è l'unica ragione per cui posso fare.

Chiedendo a un pubblico più ampio, L'interfaccia Decorater in Decorator Design Pattern è solo per fornire supporto dinamico tramite Factory o c'è dell'altro.

design-patterns decorator

posta ATul Singh 26.05.2018 - 22:16

fonte

3 risposte

Leggi altre domande sui tag design-patterns decorator

Grande manipolazione della matrice in ambiente multithread 'estendere' un caso d'uso non necessario quando è direttamente associato all'attore?

score 2 · Answer 1

Il motivo principale che posso vedere per l'interfaccia Decorator / base nel pattern Decorator è rendere chiaro nella descrizione del pattern quali sono le caratteristiche comuni di ConcreteDecorator s.

Questo significa che, a mio avviso, non ci devono essere classi distinte che corrispondono a Decorator e ConcreteDecorator quando si utilizza il pattern Decorator, specialmente se ci sono solo pochi decoratori. Quando ce ne sono molti, può essere utile avere una classe separata per il comportamento comune per ridurre la quantità di duplicazione del codice.

score 1 · Answer 2

I due principali motivi a mio avviso sono:

Rendere semanticamente chiaro cos'è un decoratore e cosa no.
Isolare il componente principale dai decoratori fornendo un punto di estensione. Puoi progettare la tua applicazione / framework di base con solo l'interfaccia decorator e lasciare che altri decoratori vengano aggiunti tramite plug-in.

In aggiunta a ciò, puoi fare ogni genere di cose interessanti come scegliere tutti i decoratori che un'istanza può usare con la riflessione.

In molti modelli l'interfaccia astratta può essere omessa, ma dovresti essere molto fiducioso che non sarà necessario in seguito. È una buona idea lasciarli lì in generale. Sono un modo molto utile per isolare componenti e modifiche.

score 0 · Answer 3

Puoi fare cose che non puoi con l'ereditarietà:

Puoi decorare classi sigillate / finali.
È possibile rimuovere o modificare il modificatore di accesso di qualsiasi membro non nell'interfaccia.
Puoi rendere virtuali i metodi non virtuali.
Puoi rimuovere attributi ereditabili.

Ad esempio, se costruisci una libreria di codici in c # che ha un oggetto molto potente, puoi fare questo:

public interface IGod 
{
    void CreateAllLife();
}

public IBasic
{
    void DoSomethingMundane();
}

internal sealed class GodObject : IBasic, IGod
{
    public void CreateAllLife() { Console.WriteLine("Let there be light"); }
    public void DoSomethingMundane() { Console.WriteLine("Burrrp."); }
}

public class Decorator : IBasic
{
    private GodObject _god;

    public virtual void DoSomethingMundane() => _god.DoSomethingMundane();
}