Pattern di conversione oggetto

Question

Ho diverse classi provenienti da fonti esterne (non modificabili) che rappresentano lo stesso concetto. Ad esempio Address. Ho com.namespace1.Address (con campi houseNum, street, city), com.namespace2.Address (con campi h, s, c), namespace3.com.CoolAddress (con campi house_num, street, city).

Il problema è che determinati servizi Web che uso richiedono determinati tipi di oggetto Indirizzo, quindi sono obbligato a creare un dato un namespace3.com.CoolAddress. I campi sono abbastanza facili da mappare ma sto cercando un modello su come farlo.

Dal mio punto di vista, un oggetto istanza AddressConverter non ha senso in quanto non esiste uno stato (solo comportamento) e quando le classi hanno solo un comportamento si riduce a metodi statici in una classe di utilità. A lungo termine, ogni volta che ho bisogno di mappare i nuovi oggetti l'uno con l'altro, ho un posto dove aggiungere/modificare/rimuovere metodi. Il modo in cui è fatto potrebbe cambiare, ma so dove si trova il codice (in una volta) e posso modificare la mappatura quando è necessario.

Pensieri?

Answer 1

Penso che quello che stai cercando è un classe di fabbrica. Il pattern factory viene utilizzato quando è necessario essere in grado di creare un'istanza di una delle varie classi correlate, che deve essere determinata dalla fabbrica, non dallo sviluppatore.

Vedi http://en.wikipedia.org/wiki/Factory_method_pattern

Hai ragione per cercare di mantenere tutto questo la logica di business in un unico luogo, invece di fare ClassOne.toClassTwo(), ClassOne.toClassThree(), ...

Il più flessibile il modo in cui posso pensare di implementare questo (ma non il più semplice di gran lunga) sarebbe quello di far partire la fabbrica con una semplice classe con solo metodi comuni di base e aggiungere gestori ad un Hashtable o ad altri container. In questo modo non hai bisogno di implementazioni concrete di ogni possibile combinazione di funzionalità.

Naturalmente sarebbe più rapido disporre di un'implementazione concreta per ogni possibile variante di indirizzo, ma ci sarebbe una buona quantità di codice duplicato e sarebbe un po 'più difficile aggiungere nuovi tipi di classe di indirizzi.

Answer 2

Poiché non è possibile modificare le classi stesse, suggerirei un'implementazione del modello Adapter per ciascuna direzione. Come hai detto, i metodi dell'adattatore possono essere statici, ma puoi raggruppare entrambe le direzioni all'interno di una singola classe in modo che la logica sia tutto in un unico punto.

Alla fine della giornata, eseguirai lo stesso compito indipendentemente da come lo chiami, o da dove inserisci il codice. Suggerirei che entrambe le direzioni risiedano nello stesso file, poiché spesso avranno bisogno di essere aggiornate quando cambiano entrambe le direzioni.

Answer 3

Se si esegue la conversione sempre nella stessa classe, è consigliabile che sia semplice e inserisca tutto il codice di conversione in quella classe senza preoccuparsi di fabbriche e simili, soprattutto se si tratta solo di un paio di classi diverse. Perché ci deve sempre essere uno schema complicato per queste cose ?!

public class A { 

    ... 

    public static A convertB(B b) { 

    ... 

    } 
} 

Answer 4

sono le classi necessarie per l'uscita final? In caso contrario, è possibile creare una sottoclasse per creare il valore corretto Adapters. Altrimenti andrei con il suggerimento di dj_segfault di una fabbrica con una tabella di gestori.

Oppure, aspetta: è solo un servizio Web con cui devi parlare? In tal caso, non ci dovrebbero essere motivi per cui le implementazioni dei suoi tipi di dati non possono essere adattatori che includono i tipi di dati di input o altri oggetti intermedi.