Pattern per guadagnare astrazione rispetto all'assemblaggio senza astrazione

Question

Pattern per guadagnare astrazione rispetto all'assemblaggio senza astrazione

#1 da (4 voti)

2

Sto interagendo con una grande base di codice (in un unico assembly) scritta da un altro dipartimento (chiamiamola BusinessAssembly). Preziosi pochi oggetti che dobbiamo usare in quell'assemblaggio usano le interfacce. Di conseguenza, molti dei nostri progetti devono fare riferimento a quell'assemblaggio perché non sono disponibili astrazioni e i test sono difficili da scrivere.

Per complicare ulteriormente le cose, ora sembra che dovremmo essere in grado di supportare più versioni di BusinessAssembly e passare da una all'altra in fase di build o di esecuzione. Per esempio. BusinessAssembly2 aggiungerà nuovi oggetti che dovremo utilizzare, ma BusinessAssembly1 non conterrà quegli oggetti.

La mia unica soluzione promettente finora è creare due progetti separati nella nostra soluzione, uno che fa riferimento a BusinessAssembly1 (BusinessProxy1) e un altro che fa riferimento a BusinessAssembly2 (BusinessProxy2). Questi progetti conterrebbero proxy e decoratori attorno ai singoli oggetti BusinessAssembly (ad esempio BusinessUserProxy) e tali proxy e decoratori implementerebbero le interfacce (IBusinessUserProxy).

Se ho riflettuto correttamente su questo, una fabbrica astratta potrebbe quindi fornire l'oggetto proxy / decoratore richiesto dal progetto proxy / decoratore corretto in fase di esecuzione e gli altri nostri progetti potrebbero abbandonare i loro riferimenti all'assemblaggio gigante e utilizzare semplicemente le interfacce implementate dai vari proxy / decoratori.

Non sto cercando di alterare il comportamento degli oggetti, ma un'altra considerazione qui è che noi vorremmo piacere ottenere la possibilità di fornire duplicati di prova per i vari oggetti BusinessAssembly, che questo approccio dovrebbe fornire.

Tuttavia, questo approccio comporta una notevole quantità di costi di sviluppo: quando BusinessAssembly3 crea dieci nuovi oggetti, è necessario scrivere proxy e interfacce per ciascuno di essi.

Le mie domande: è un uso accettabile dei proxy semplicemente fornire un'interfaccia per un oggetto che altrimenti non ha un'interfaccia? Un approccio diverso eviterebbe il sovraccarico di sviluppo?

Inoltre, ora sono terribilmente malato quindi fammi sapere se non sono chiaro o se in realtà non ho nemmeno scritto nessuna parola vera.

c# design-patterns

posta Pete Scott 12.10.2014 - 02:53

fonte

1 risposta

Leggi altre domande sui tag c# design-patterns

Come testare la migliore combinazione di rapporti per adattarsi a un rapporto globale? Evita correttamente l'ereditarietà?

score 4 · Accepted Answer

Se BusinessAssembly2 contiene tutti i membri pubblici di BusinessAssembly1 , allora potresti scrivere una o più interfacce per quel sottoinsieme di membri, che potrebbe essere usato come parametro costruttore in una o più classi di Facade, fornendo quindi Dipendenza Iniezione. Ciò consentirebbe di passare da una delle versioni degli assiemi aziendali sottostanti in fase di progettazione o di esecuzione, secondo necessità.

Ti consentirebbe anche di creare classi di test che implementano tali interfacce e di trasferirle nella facciata per scopi di test.

Dovresti comunque creare o estendere le tue classi Interfacce e Facade quando è uscito BusinessAssembly3 . Non vedo in alcun modo che, a meno che l'utilizzo diretto delle nuove classi sia accettabile.

Se quegli assembly aziendali sono grandi, potresti risparmiare un sacco di noioso lavoro manuale costruendo un piccolo generatore di codice che li ha controllati tramite Reflection e le classi di interfacce e facciate di output.