Patrón de conversión de objeto

Question

Tengo varias clases diferentes procedentes de fuentes externas (no modificables) que representan el mismo concepto. Por ejemplo Address. Tengo com.namespace1.Address (con campos houseNum, street, city), com.namespace2.Address (con campos h, s, c), namespace3.com.CoolAddress (con campos house_num, street, city).

El problema es que ciertos servicios web que uso requieren ciertos tipos de objetos de dirección, por lo que debo crear un com.namespace1.Address dado un namespace3.com.CoolAddress. Los campos son fáciles de mapear, pero estoy buscando un patrón sobre cómo hacerlo.

Desde mi punto de vista, un objeto instancia AddressConverter no tiene sentido ya que no hay estado (solo comportamiento) y cuando las clases solo tienen comportamiento se reduce a métodos estáticos en una clase de utilidad. A largo plazo, cada vez que necesite mapear objetos nuevos entre sí, tengo un lugar para agregar/modificar/eliminar métodos. Cómo se hace puede cambiar, pero sé dónde se encuentra el código (en un lugar) y puedo cambiar el mapa cuando sea necesario.

¿Pensamientos?

Answer 1

Creo que lo que estás buscando es clase de fábrica. El patrón de fábrica se usa cuando necesita poder crear una instancia de una de varias clases relacionadas, que será determinada por la fábrica, no por el desarrollador.

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

Tienes razón para tratar de mantener toda esta lógica de negocio en un solo lugar en vez de hacer ClassOne.toClassTwo(), ClassOne.toClassThree(), ...

El más flexible De la manera en que puedo pensar en implementar esto (pero no el más fácil por el momento) sería hacer que la fábrica comience con una clase simple con solo métodos comunes básicos y agregar manejadores a una Hashtable u otro contenedor. De esta forma, no necesita implementaciones concretas de todas las combinaciones posibles de características.

Por supuesto, sería más rápido tener una implementación concreta para cada posible variante de dirección, pero habría una buena cantidad de código duplicado, y sería un poco más difícil agregar nuevos tipos de clases de direcciones.

Answer 2

Como no puede modificar las clases, le sugiero una implementación del patrón Adapter para cada dirección. Como dijiste, los métodos del adaptador en sí mismos pueden ser estáticos, pero puedes agrupar ambas direcciones dentro de una sola clase para que la lógica esté en un solo lugar.

Al final del día, realizará la misma tarea sin importar cómo la llame o dónde coloque el código. Sugeriría que ambas direcciones vivan en el mismo archivo, ya que a menudo ambas necesitarán actualizarse cuando cambie cualquier dirección.

Answer 3

Si siempre está convirtiendo a la misma clase, lo mantendría simple y pondría todo el código de conversión en esa clase y no se preocupara por fábricas y similares, especialmente si solo está tratando con un par de clases diferentes. ¿Por qué siempre tiene que haber un patrón complicado para estas cosas?

public class A { 

    ... 

    public static A convertB(B b) { 

    ... 

    } 
} 

Answer 4

Son las clases que necesita para generar final? De lo contrario, podría crear una subclase para crear el Adapters adecuado. De lo contrario, iría con la sugerencia de dj_segfault de una fábrica con una tabla de controladores.

O, espera, ¿es solo un servicio web con el que necesitas hablar? Si es así, no debería haber ninguna razón para que las implementaciones de sus tipos de datos no puedan ser adaptadores que envuelvan los tipos de datos de entrada, o algún objeto intermedio propio.