Separación de preocupaciones al agregar nuevos tipos

7

Tengo un sistema en el que he estado trabajando esta semana, donde me cuesta trabajo equilibrar la separación de inquietudes con la facilidad de ampliación. Estoy agregando nuevos tipos al sistema, y se siente como una cirugía de escopeta.

La idea básica es que los datos se recopilan (sondean) desde un sistema remoto y luego se ponen a disposición de diferentes tipos de clientes. Para admitir su tipo de interfaz (protocolo), estoy haciendo muchas traducciones.

Voy a intentar simplificar esto para que pueda encajar en un cuadro de preguntas.

Hay un FruitService en el mundo con una interfaz SNMP. El trabajo de mi editor es recopilar esos datos y luego publicarlos.

  1. Entonces, para cada tipo de fruta nueva que decidamos publicar, creo una clase que sabe cómo extraer los atributos de esa fruta a través de SNMP.
  2. Internamente Fruit se traduce a DTO (los mismos objetos utilizados para hablar con el cliente # 1 (RMI)).
  3. Se actualiza una memoria caché y se verifican los cambios para desencadenar notificaciones asíncronas.
  4. Una clase para traducir la fruta al esquema xml utilizado por otro cliente (# 2).
  5. Una clase para traducir la fruta en pares de atributos / valores simples utilizados por otro cliente (# 3).

Al final creo 5 clases y edito 8 más para conectar un nuevo tipo. No es mucho trabajo; Un par de horas para escribir código, prueba y registro para un tipo simple. Tenga en cuenta que no hay muchos puntos en común en los tipos de fruta (por ejemplo, pera y coco), por lo que la mayoría de las abstracciones comunes se basan en el proceso de actualización de los datos y no en los datos en sí.

Mis preocupaciones de diseño son:

  1. La interfaz SNMP cambia 2-3 veces al año
  2. El esquema xml (cliente 2) cambia 10 veces al año.
  3. La adición de nuevos tipos ocurre con menos frecuencia, generalmente cuando alguien lo hace. Pero tal vez si fuera más fácil ...

Por lo tanto, el objetivo teórico con el diseño era manejar esos cambios externos fácilmente. Esto condujo a toda la separación en las capas de traducción. Pero agregar tipos se siente más difícil de lo que me gustaría.

¿Hay alguna técnica o ejemplo que pueda examinar? ¿Una idea que me falta? ¿Estoy aplicando SRP de forma incorrecta y debería haber un tipo de Apple que hable SNNP, esquema xml, DTO, etc.?

EDITAR:

El cliente # 1, el cliente de RMI, se escribe de forma personalizada cuando se agrega una nueva fruta, para aprovechar todas las capacidades de la fruta. Entonces, si decidimos obtener información sobre el banano del FruitService, también escribiremos un cliente que le permita pelar el plátano, recibir una notificación cuando esté madura y decirle a qué grupo pertenece, junto con los atributos básicos de la fruta, como el tamaño, peso, color, tiempo hasta podrido, etc.

    
pregunta Steve Jackson 09.09.2010 - 15:40

1 respuesta

1

Mi primera impresión es que su diseño necesita un poco de refactorización para estar más orientado a objetos. Tienes diferentes tipos para diferentes estructuras, sin embargo el comportamiento es importante. Si es posible en lugar de crear un nuevo tipo de fruta, describa la estructura genérica de la fruta y cree objetos para la fruta concreta. De esta manera, puede incluir el comportamiento que describirá la estructura en Fruit y creará clases de traducción genéricas, que solo utilizarán la información sobre la estructura para crear los 8 objetos que necesita cuando agregue un nuevo tipo de fruta. Esto también se puede hacer utilizando metaprogramación, pero depende de su idioma y las habilidades y el esfuerzo necesarios para crear algo así.

Así que la idea es traducir Coconut.getMilk () y Pear.getSeeds () a Fruit.getAttributes () y así sucesivamente. ¿Esto ayuda un poco?

    
respondido por el Gabriel Ščerbák 10.09.2010 - 13:03

Lea otras preguntas en las etiquetas