L'adattatore è il modello di progettazione corretto per questa situazione?

Question

L'adattatore è il modello di progettazione corretto per questa situazione?

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

0

Ho un'istanza di una classe UntouchableClass di cui ho bisogno per accedere alle variabili membro da utilizzare nel mio modello DotLiquid. Il problema è che UntouchableClass deve ereditare da Drop se voglio usarlo nel mio modello, ma non posso cambiarlo dato che proviene da una libreria esistente.

Ho letto del pattern dell'adapter, ma UntouchableClass non ha un'interfaccia da cui ereditare l'adattatore.

Inoltre, non posso usare ereditarietà multipla (creerei una classe che eredita sia da UntouchableClass sia da Drop ma questo è C # e da quello che so non è possibile).

Esiste uno schema di progettazione adatto a questa situazione? O c'è un modo particolare per farlo usando DotLiquid?

c# design-patterns .net

posta Deinonychus 07.03.2014 - 18:34

fonte

3 risposte

Leggi altre domande sui tag c# design-patterns .net

Un buon modo per imparare una lingua e comprenderne appieno le caratteristiche e le classi è provare tutti i metodi nell'API [chiuso] Come faccio a creare ogni permutazione [chiuso]

score 6 · Answer 1

Sì, il modello dell'adattatore è appropriato qui. Guardando l'articolo di wikipedia per il pattern Adapter, ci sono due versioni, la 'Object Adapter Pattern' e la 'Class Adapter Pattern'. Nell'Object Adapter Pattern, l'adattatore contiene un'istanza della classe adattata, mentre nel Pattern Adapter Class, l'adattatore entra dall'adattatore.

La limitazione che descriveresti ti impedirebbe probabilmente di utilizzare il Pattern dell'adattatore di classe. Tuttavia, dovresti comunque essere in grado di utilizzare il Pattern adattatore adattatore. Devi semplicemente avere un'istanza della classe che vuoi adattare (il modo appropriato di istanziare e persistere molto probabilmente dipenderà dalla situazione). Ogni metodo che vuoi sovrascrivere o implementare da Drop potrebbe quindi essere una chiamata al metodo sull'oggetto adattato wrapping.

score 0 · Answer 2

+1 @Ben Aaronson, BTW. Buona risposta.

Considero l'ereditarietà come una forma di composizione implicita, in cui il compilatore sta facendo il lavoro intenso della composizione per te. Ci sono differenze e conseguenze molto diverse, ma di conseguenza non mi preoccupo così tanto quando passo all'una o all'altra.

Una delle principali differenze, tuttavia, è che quando si utilizza la composizione per creare una classe su un'altra, non si è limitati da ciò che è la classe base. In questo caso va bene - è esattamente ciò di cui hai bisogno.

In questo caso, il problema centrale è il polimorfismo. Devi implementare una sottoclasse di Drop . Per il mondo esterno, la tua classe deve apparire come Drop . Se la tua implementazione è in realtà solo un wrapper, ovvero un adattatore, che delega fino a un'istanza di UntouchableClass , va bene.

IMHO il vero valore dei modelli di design è la comprensione ad un livello molto dettagliato perché funzionano.

score 0 · Answer 3

Non accetterò la mia risposta poiché non è direttamente collegata alla mia domanda, ma ecco cosa ha funzionato:

DotLiquid ha regole diverse per i parametri di rendering del modello. Pensavo che l'ereditarietà di Drop fosse essenziale, ma risulta che è solo one condizione possibile .

Esiste un metodo chiamato Template.RegisterSafeType(Type type, string[] allowedMembers) creato appositamente per questo caso.

Per alcuni esempi, vedi qui: TemplateTests