Erstellen einer erweiterbaren Eigenschaftenklasse (OOP)

Question

Ich habe eine Anwendung, die mehrere Typen und Versionen einiger Geräte unterstützt. Es kann sich mit diesen Geräten verbinden und verschiedene Informationen abrufen.

Je nach Gerätetyp habe ich (unter anderem) eine Klasse, die verschiedene Eigenschaften enthalten kann. Einige Eigenschaften sind allen Geräten gemeinsam, einige sind für ein bestimmtes Gerät eindeutig.

Diese Daten werden in XML serialisiert.

Was wäre ein bevorzugter Weg, um eine Klasse zu implementieren, die zukünftige Eigenschaften in zukünftigen Versionen dieser Geräte unterstützt, sowie rückwärtskompatibel zu früheren Anwendungsversionen?

Ich kann von mehreren Möglichkeiten denken, aber ich finde keine von ihnen groß:

• Verwenden Sie eine Auflistung von Name-Wert-Paare:
  • Profis: gute Abwärtskompatibilität (XML und frühere Versionen meiner App) und Erweiterbarkeit,
  • Nachteile: keine Art Sicherheit, keine Intellisense, erfordert die Implementierung von benutzerdefinierten XML-Serialisierung (um verschiedene value Objekte)
• abgeleitet Erstellen Eigenschaften Klasse für jedes neue Gerät:
  • Profis: Typsicherheit
  • Nachteile: haben XmlInclude oder benutzerdefinierte Serialisierung verwenden abgeleiteten Klassen deserialisieren, nicht rückwärts Kompatibilität mit vorherigen XML-Schema (obwohl durch die Implementierung benutzerdefinierter Serialisierung I könnte überspringen unbekannte Eigenschaften?), erfordert Casting für den Zugriff auf Eigenschaften in abgeleiteten Klassen.
• Eine andere Möglichkeit, es zu tun?

Ich benutze C#, übrigens.

Answer 1

Wie wäre es mit einer ähnlichen PropertyBag?

Answer 2

Ich glaube, dass das Erstellen abgeleiteter Eigenschaften die beste Wahl ist.

Sie können Ihre neuen Klassen mithilfe des XML-Schemas entwerfen. Und dann generiere einfach den Klassencode mit xsd.exe.

Mit .net ist nicht schwer, eine generische Klasse zu entwickeln, die alle Typen zu und von XML serialisieren und deserialisieren kann.

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 gesprochen, das klingt wie es ein Job für die Decorator Pattern sein könnte. Im Wesentlichen haben Sie eine Superklasse, die eine gemeinsame Schnittstelle für all diese Gerätetypen definiert. Dann haben Sie Decorator-Klassen, die andere Eigenschaften haben, die ein Gerät haben könnte. Beim Erstellen dieser Geräte können Sie diese Dekorationen dynamisch hinzufügen, um neue Eigenschaften für das Gerät zu definieren.Grafisch:

Sie auf der Wikipedia-Seite für eine detailliertere Beschreibung suchen. Danach wäre es nur eine Frage der Serialisierung, dem Programm mitzuteilen, welche Dekoratoren geladen werden sollen.

Answer 4

Wenn Sie nicht auf die Interoperabilität mit einem externen Schema beschränkt sind, sollten Sie Runtime Serialization und SoapFormatter verwenden. Das Muster für die Laufzeitserialisierung ermöglicht abgeleiteten Klassen, anzugeben, welche ihrer Eigenschaften serialisiert werden müssen und was mit ihnen bei der Deserialisierung zu tun ist.

Der XML-Serializer benötigt XmlInclude, da er das zu verwendende Schema definieren muss.

Answer 5

Ich mag Name/Wert-Sets für diese Art von Sache.

Viele Ihrer Nachteile können behandelt werden - betrachten Sie eine Basisklasse, die als allgemeiner Name/Wert mit No-Op-Methoden für die Validierung eingehende Name/Wert-Paare fungiert. Für bekannte Mengen von Namen (d. H. Schlüssel) können Sie abgeleitete Klassen erstellen, die Validierungsmethoden implementieren.

Zum Beispiel kann der Drucker einen bekannten Schlüssel "PrintsColor" haben, der nur "wahr" oder "falsch" sein kann. Wenn jemand versucht, PrintsColor = "CMYK" zu laden, würde Ihre Druckerklasse eine Ausnahme auslösen.

Je nachdem, was Sie tun, können Sie verschiedene Wege gehen, um die Validierung bequemer zu machen - Hilfsmethoden in der Basisklasse (zB checkForValidBoolean()) oder eine Basisklasse, die Name/Typ akzeptiert Informationen in seinem Konstruktor für saubereren Code in Ihren abgeleiteten Klassen und möglicherweise eine weitgehend automatisierte XML-Serialisierung.

Für Intellisense - Ihre abgeleiteten Klassen könnten grundlegende Zugriffsmethoden haben, die in Bezug auf die Schlüsselsuche implementiert werden. Intellisense würde diese Accessor-Namen präsentieren.

Dieser Ansatz hat für mich gut funktioniert - es gibt eine gewisse Kurzsichtigkeit gegenüber dem klassischen OO-Design, besonders bei großen Systemen mit eingesteckten Komponenten. IMO, die clunkierartige Art, die hier überprüft wird, ist ein großes von einem Widerstand, aber die Flexibilität macht es lohnend.

Answer 6

Die allgemeine Idee, was Sie hier erreichen wollen, ist genau das, was das EAV Muster löst. EAV ist ein Muster, das am häufigsten in der Datenbankentwicklung verwendet wird, aber das Konzept ist gleichermaßen für Anwendungen gültig.