Qual è la differenza tra i modelli di design di facciata, proxy, adattatore e decoratore?
Non ho mai letto una spiegazione chiara, qual è la tua?
Qual è la differenza tra i modelli di design di facciata, proxy, adattatore e decoratore?
Non ho mai letto una spiegazione chiara, qual è la tua?
Risposte:
L'adapter adatta una determinata classe / oggetto a una nuova interfaccia. Nel primo caso, l'ereditarietà multipla è tipicamente impiegata. In quest'ultimo caso, l'oggetto viene avvolto da un oggetto adattatore conforme e passato. Il problema che stiamo risolvendo qui è quello delle interfacce non compatibili .
La facciata è più simile a un semplice gateway per un insieme complicato di funzionalità. Crea una scatola nera di cui i tuoi clienti devono preoccuparsi di meno, ovvero rendere le interfacce più semplici .
Il proxy fornisce la stessa interfaccia della classe proxy e in genere esegue alcune operazioni di pulizia da solo. (Quindi, invece di fare più copie di un oggetto pesante X
, fai copie di un proxy leggero P
che a sua volta gestisce X
e traduce le tue chiamate come richiesto.) Stai risolvendo il problema del client dal dover gestire un oggetto pesante e / o complesso .
Decorator viene utilizzato per aggiungere più polvere da sparo ai tuoi oggetti (nota il termine oggetti - in genere decori oggetti dinamicamente in fase di esecuzione). Non nascondere / compromettere le interfacce esistenti dell'oggetto ma semplicemente estenderlo in fase di esecuzione .
Ora che hai un decoratore coinvolto, probabilmente vorrai sapere perché l'enfasi sull'oggetto parola - alcuni linguaggi (come Java) semplicemente non consentono l'ereditarietà virtuale (cioè l'eredità multipla come fa C ++) per permetterti di realizzare questo in tempo di compilazione.
Dato che abbiamo trascinato in più eredità (e il temuto diamante), dovrai cercare i mixin , che sono ordinati concatenamento lineare di interfacce per aggirare i problemi dell'ereditarietà multipla. Tuttavia, i mixin non si mescolano così bene. E finiamo con i tratti - sì, quei piccoli blob di comportamento apolidi che vedi comparire continuamente nei parametri dei template in C ++. I tratti cercano di affrontare i problemi di composizione e decomposizione del comportamento in modo elegante, senza andare per eredità multiple o concatenamento ordinato.
Facciata
È possibile utilizzare una facciata, ad esempio, per semplificare le chiamate a un'API. Dai un'occhiata a questo esempio di facciata remota. L'idea qui è che la piena implementazione del codice sul server sia nascosta al client. Il client chiama 1 metodo API che, a sua volta, può effettuare 1 o più chiamate API sul server.
Adattatore
Un buon esempio di questo può essere trovato qui , su Wikipedia. Un oggetto client Source
vorrebbe chiamare un metodo su un altro oggetto Target
, ma l'interfaccia di quell'altro oggetto differisce da ciò che il client si aspetta.
Immettere l'oggetto adattatore.
Può ricevere una chiamata Source
dall'oggetto e, dietro le quinte, chiamare il Target
metodo che dovrebbe essere usato.
Source->CallMethodAOnTarget() ---< Adaptor.CallMethodAOnTarget() this calls ---> Target.MethodWithDifferentSignatureAndName(int i)
Per quanto riguarda Proxy, non ho alcuna esperienza di questo modello di progettazione.