schema a ponte e motivo decoratore

Question

Qualcuno può elaborare per me il modello di progettazione Bridge e il motivo Decoratore. L'ho trovato simile in qualche modo. Non so come distinguerlo?

La mia comprensione è che in Bridge, separa l'implementazione dall'interfaccia, in genere è possibile applicare solo un'implementazione. Decoratore è una specie di involucro, puoi avvolgerne il maggior numero possibile.

Per esempio,

Ponte modello

class Cellphone { 
private: 
Impl* m_OS;   // a cellphone can have different OS 

} 

Decorator modello

class Shirt { 
private: 
Person * m_p;   //put a shirt on the person; 

} 

Answer 1

Il decoratore deve corrispondere l'interfaccia dell'oggetto che si sta decorando. cioè ha gli stessi metodi e consente l'intercettazione degli argomenti sulla via d'ingresso e del risultato sulla via d'uscita. È possibile utilizzarlo per fornire un comportamento aggiuntivo all'oggetto decorato mantenendo la stessa interfaccia/contratto. Si noti che l'interfaccia di Decorator può fornire funzionalità aggiuntiva per creare un oggetto più utile.

Il Bridge non ha questo vincolo. L'interfaccia client-facing può essere diversa dal componente sottostante che fornisce l'implementazione e quindi è ponticelli tra l'interfaccia del client e l'effettiva implementazione (che potrebbe non essere adatta ai clienti, soggetto a modifiche ecc.)

Answer 2

l'implementazione del modello decoratore non è giusto - si avrebbe più senso se si ha:

class PersonWearingShirt : IPerson 
{ 
private: 
    IPerson * m_p;   //put a shirt on the person; 

} 

l'idea è che, quando si decorare una classe, si espone la stessa interfaccia esatto. Questo fa apparire l'istanza "decorata" e si comporta come l'originale. Ciò consente di avvolgere un'istanza molte volte con più decoratori, ma trattarla esattamente come si gestisce l'istanza originale.

Answer 3

Brian è corretto. Aggiungerò ciò concettualmente, il client "saprà" che sta usando un bridge per un oggetto sottostante, ma con un decoratore, il cliente non sarà in grado di sapere che c'è un livello decoratore tra esso e l'oggetto di destinazione.

Lo scopo del bridge è creare un livello di astrazione per proteggere il client. Lo scopo del decoratore è di aggiungere funzionalità all'oggetto senza che il client lo sappia. La maggior parte dei decoratori passerà tutte le chiamate di funzione direttamente a un puntatore alla loro classe genitore, ad eccezione delle funzioni relative direttamente a ciò che il decoratore è progettato per cambiare.

Answer 4

Decorator:

1. aggiungere un comportamento di opporsi in fase di esecuzione. L'ereditarietà è la chiave per ottenere questa funzionalità, che è allo stesso tempo il vantaggio e lo svantaggio di questo modello.
2. Migliora il comportamento dell'interfaccia.
3. Il decoratore può essere visualizzato come un composito degenerato con un solo componente. Tuttavia, un decoratore aggiunge ulteriori responsabilità: non è inteso per l'aggregazione di oggetti.
4. Il decoratore supporta la composizione ricorsiva
5. La classe Decorator dichiara una relazione di composizione con l'interfaccia LCD (Lowest Class Denominator) e questo membro di dati è inizializzato nel suo costruttore.
6. Decorator è progettato per consentire di aggiungere responsabilità agli oggetti senza sub-classing

Fare riferimento alla sourcemaking articolo per ulteriori dettagli.

diagramma UML di decoratore da wikipedia: Reticolo

Ponte:

1. Bridge schema strutturale
2. astrazione e attuazione non sono vincolati in fase di compilazione
3. Astrazione e implementazione zione - entrambi possono variare senza impatto nel client

Utilizzare il modello di ponte quando:

1. si desidera eseguire in tempo vincolante dell'attuazione,
2. voi hanno una proliferazione di classi derivanti da un accoppiato interfaccia e numerose implementazioni,
3. se si desidera condividere un'implementazione tra più oggetti, è necessario mappare gerarchie di classi ortogonali.

diagramma UML Ponte da wikipedia:

Dal diagramma UML, si può osservare la differenza:

Nel modello decoratore, decoratore sta attuando componenti, che sarà essere sostituito da ConcreteComponent in fase di esecuzione.

Nel modello Bridge, RedefinedAbstraction non sta implementando Implementor. Invece, utilizza la composizione in modo che Implementor possa variare dinamicamente in fase di esecuzione senza la conoscenza del client.

Decoratore non può disaccoppiare l'astrazione dall'implementazione a differenza del modello Bridge.

qualche post più utili:

When to Use the Decorator Pattern?

When do you use the Bridge Pattern? How is it different from Adapter pattern?