Crear una clase de propiedades extensibles (OOP)

Question

Tengo una aplicación que admite varios tipos y versiones de algunos dispositivos. Se puede conectar a estos dispositivos y recuperar diversa información.

Dependiendo del tipo de dispositivo, tengo (entre otras cosas) una clase que puede contener varias propiedades. Algunas propiedades son comunes a todos los dispositivos, algunas son exclusivas de un dispositivo en particular.

Estos datos se serializan a xml.

¿Cuál sería una forma preferida de implementar una clase que admitiría futuras propiedades en futuras versiones de estos dispositivos, y también sería compatible con versiones anteriores de la aplicación?

puedo pensar en varias maneras, pero me parece que ninguno de ellos grandes:

• utilizar una colección de pares nombre-valor:
  • pros: buena compatibilidad con versiones anteriores (tanto xml y versiones anteriores de mi aplicación) y extensibilidad,
  • contras: ningún tipo de seguridad, no intellisense, requiere la implementación de la serialización xml personalizada (para manejar diferentes value objetos)
• Crear clase derivada propiedades para cada dispositivo nuevo:
  • pros: Tipo de seguridad
  • contras: tener que utilizar XmlInclude o serialización personalizada deserializar clases derivadas, no hacia atrás compatibilidad con el esquema xml previo (aunque implementando serialización personalizada I podría omitir propiedades desconocidas?), requiere conversión para acceder a propiedades en clases derivadas.
• ¿Otra forma de hacerlo?

Estoy usando C#, por cierto.

Answer 1

¿Qué tal algo similar a un PropertyBag?

Answer 2

Creo que la creación de propiedades derivadas es la mejor opción.

Puede diseñar sus nuevas clases utilizando el esquema xml. Y luego simplemente genere el código de clase con xsd.exe.

Con .net no es difícil desarrollar una clase genérica que pueda serializar y deserializar todos los tipos hacia y desde xml.

public static String toXmlString<T>(T value) 
{ 
    XmlSerializer xmlSerializer = new XmlSerializer(typeof(T)); 
    StringWriter stringWriter = new StringWriter(); 
    try { xmlSerializer.Serialize(stringWriter, value); } 
    catch (Exception e) 
    { 
     throw(e); 
    } 
    finally { stringWriter.Dispose(); } 
    String xml = stringWriter.ToString(); 
    stringWriter.Dispose(); 
    return xml; 
} 

public static T fromXmlFile<T>(string fileName, Encoding encoding) 
{ 
    Stream stream; 
    try { stream = File.OpenRead(fileName); } 
    catch (Exception e) 
    { 

     e.Data.Add("File Name", fileName); 
     e.Data.Add("Type", typeof(T).ToString()); 
     throw(e); 
    } 

    BufferedStream bufferedStream = new BufferedStream(stream); 
    XmlSerializer xmlSerializer = new XmlSerializer(typeof(T)); 

    TextReader textReader; 
    if (encoding == null) 
     textReader = new StreamReader(bufferedStream); 
    else 
     textReader = new StreamReader(bufferedStream, encoding); 

    T value; 
    try { value = (T)xmlSerializer.Deserialize(textReader); } 
    catch (Exception e) 
    { 
     e.Data.Add("File Name", fileName); 
     e.Data.Add("Type", typeof(T).ToString()); 
     throw(e); 
    } 
    finally 
    { 
     textReader.Dispose(); 
     bufferedStream.Dispose(); 
    } 
    return value; 
} 

Answer 3

Programatically hablando, esto suena como que podría ser un trabajo para el Decorator Pattern. Básicamente, tienes una súper clase que define una interfaz común para todos estos tipos de dispositivos. Luego tiene clases de decorador que tienen otras propiedades que un dispositivo podría tener. Y, al crear estos dispositivos, puede agregar dinámicamente estas decoraciones para definir nuevas propiedades para el dispositivo.Gráficamente:

Usted puede mirar en la página de Wikipedia para obtener una descripción más detallada. Después de eso, solo sería cuestión de hacer una serialización para decirle al programa qué decoradores cargar.

Answer 4

Si no está limitado a la interoperabilidad con un esquema externo, entonces debe usar Serialización en tiempo de ejecución y SoapFormatter. El patrón de serialización en tiempo de ejecución permite que las clases derivadas especifiquen cuáles de sus propiedades necesitan ser serializadas y qué hacer con ellas cuando se deserializan.

XML Serializer requiere XmlInclude porque, en efecto, necesita definir el esquema que se usará.

Answer 5

Me gustan los juegos de nombre/valor para este tipo de cosas.

Muchos de sus inconvenientes pueden resolverse: considere una clase base que actúe como un conjunto de nombre/valor general con métodos no operativos para validar pares de nombre/valor entrantes. Para conjuntos conocidos de nombres (es decir, claves), puede crear clases derivadas que implementen métodos de validación.

Por ejemplo, la impresora puede tener una clave conocida "PrintsColor" que solo puede ser "verdadera" o "falsa". Si alguien intenta cargar PrintsColor = "CMYK", su clase de Impresora arrojaría una excepción.

Dependiendo de lo que esté haciendo, puede realizar diferentes formas de hacer la validación más conveniente: métodos de utilidad en la clase base (por ejemplo, checkForValidBoolean()) o una clase base que acepte nombre/tipo información en su constructor para un código más limpio en sus clases derivadas, y tal vez una serialización de XML mayormente automatizada.

Para intellisense: sus clases derivadas podrían tener accesadores básicos que se implementan en términos de búsqueda de claves. Intellisense presentaría esos nombres de acceso.

Este enfoque me ha funcionado bien: hay una especie de miopía en el diseño OO clásico, especialmente para sistemas grandes con componentes enchufados. IMO, la comprobación del tipo de clunkier aquí es muy difícil, pero la flexibilidad hace que valga la pena.

Answer 6

La idea general de lo que está tratando de lograr aquí es precisamente lo que resuelve el patrón EAV. EAV es un patrón más comúnmente utilizado en el desarrollo de bases de datos, pero el concepto es igualmente válido para las aplicaciones.