Domanda di progettazione: questo è un buon esempio per il pattern proxy o "over done"?

Naviga le tue risposte
3

Lavorando su un importante miglioramento per il codice legacy, ho discusso con me stesso sul fatto che questo sia un buon caso per usare il pattern Proxy, e in particolare se un buon caso usa l'API Java Dynamic Proxy.

SFONDO Abbiamo una classe "FIXConnection" utilizzata per inviare ordini a una destinazione. L'applicazione mantiene da 1 a n FIXConnections per l'invio (viene selezionato un oggetto specifico in base a ciò che l'utente ha specificato nell'ordine).

Normalmente, l'ordine verrebbe inviato direttamente sul mercato. Il miglioramento consiste nel vedere se l'ordine potrebbe essere riempito da altri ordini già inviati sul mercato prima dell'invio e, se può essere riempito, eseguire una logica completamente diversa (cioè non inviare). In caso contrario, delega alla logica corrente.

Questa funzione sarà utilizzata solo da un client, quindi viene attivata / disattivata in modo dinamico (o tramite l'impostazione di configurazione).

Sembra che questo sia un buon uso per il pattern Proxy / Dynamic Proxy, perché consentirebbe di progettare un blocco di codice per intercettare le richieste al metodo FIXConnection.send esistente (e anche al suo metodo processResponse), solo nel caso se la funzione è abilitata. Il proxy può eseguire la nuova logica (se giustificata) o inviare alla logica esistente.

PROS AND CONS
PRO

  • L'utilizzo del proxy evita qualsiasi problema con la gerarchia di classi (occasionalmente sottoclassi questa classe FIXConnection). Se gestiamo questo per sottoclasse, potrebbe essere necessario spostare altri figli in questo sotto come genitore.

  • Non è necessario aggiornare la classe di livello superiore esistente con alcun flag per verificare se questa funzione è abilitata e per eseguire in modo condizionale il codice. (Ad esempio, non creare codice per un caso speciale, che ora verrebbe colpito da tutti i casi).

  • Un singolo punto di controllo

CON

  • La classe esistente espone le variabili pubbliche, tutto dovrebbe essere refactored nei metodi getter / setter e deve estrarre un'interfaccia (in modo che Dynamic Proxy possa essere utilizzato). cioè un'increspatura attraverso altre classi.

  • Il legame tra il proxy e il metodo legacy potrebbe essere un po 'approssimativo (ad es. method.getName (). equals ("send"). Ci sono modi di legare più strettamente, ma ... (yuck?)

  • Questo rende le cose inutilmente complicate? In generale, cerco di iscrivermi a fare "la cosa più semplice che possa funzionare". Questo non sembra proprio.

Mi piacerebbe sentire i pensieri di qualcuno su come potrebbero gestire questa domanda di design.

    
posta Sam Goldberg 05.07.2011 - 19:06
fonte

2 risposte

3

La cosa importante qui è quali sono le probabilità che avrai bisogno di farlo per altri clienti? Se le probabilità di qualsiasi altro cliente che utilizza questo sono da basso a zero, il refactoring potrebbe essere un sacco di tempo e fatica per qualcosa con un impatto molto minore. Tuttavia, se pensi che questo potrebbe essere un miglioramento che farai per più clienti, vorrei andare avanti e apportare la modifica al codice.

Se fai refactoring, penso che il modello Strategy sia più adatto a questa particolare situazione. Sembra che tu non stia tanto cercando un oggetto che funzioni al posto di un altro oggetto, quanto tenti di alterare il comportamento del server in base alla situazione specifica. I client (sto assumendo a questo punto che alla fine questo verrà utilizzato da più di 1 client) che utilizzerebbero questo miglioramento utilizzerebbero una strategia che controlla gli ordini esistenti prima di inviare un nuovo ordine, altri client userebbero una strategia che invia sempre ordini al mercato. Quando i client iniziano a utilizzare questa funzione, utilizzano la strategia appropriata con modifiche minime sulla parte.

    
risposta data 05.07.2011 - 19:57
fonte
1

Penso che la maggior parte degli svantaggi affrontati sia il risultato di una cattiva scelta di progettazione che precede il tuo lavoro.

Non rifattorizzare è la soluzione che aumenta il debito tecnico. A volte va bene, ad esempio quando devi rispettare una scadenza ravvicinata, ma a lungo termine costa più del refactoring. Inoltre, più sceglierai di non refactoring, più difficile sarà il refactoring.

Quindi, sicuramente utilizzerei il pattern e il refactoring. Dovresti comunque controllarlo con il tuo project manager, potrei sapere che non lo sei. Spiega che il lavoro che svolgerai con il refactoring dovrà essere fatto a un certo punto, o costerà molto all'azienda quando arriverà il momento di aggiungere funzionalmente o affrontare bug noiosi.

Puoi leggere questo: link per sapere cosa succede quando scegli il lato drak del codice.

    
risposta data 05.07.2011 - 19:31
fonte

Leggi altre domande sui tag

Capacità di avviare un componente aggiuntivo GPL GPL-ize un programma (Gstreamer) Qual è il modo migliore per gestire le sessioni di Hibernate in un'applicazione Struts-1?