Создание расширяемого класса свойств (ООП)

Я считаю, что создание производных свойств - лучший выбор.

Вы можете проектировать свои новые классы, используя xml-схему. А затем просто сгенерируйте код класса с помощью xsd.exe .

С помощью .net несложно разработать общий класс, который может сериализовать и десериализовать все типы в и из 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;
}

Мне нравятся наборы имен / значений для такого рода вещей.

Со многими вашими недостатками можно справиться - рассмотрите базовый класс, который действует как общий набор имени / значения без -op методы проверки входящих пар имя / значение. Для известных наборов имен (т.е. ключей) вы можете создавать производные классы, реализующие методы проверки.

Например, Printer может иметь известный ключ «PrintsColor», который может быть только «true» или «false». Если кто-то попытается загрузить PrintsColor = "CMYK", ваш класс Printer выдаст исключение.

В зависимости от того, что вы делаете, вы можете использовать несколько разных способов сделать проверку более удобной - служебные методы в базовый класс (например, checkForValidBoolean ()) или базовый класс, который принимает информацию об имени / типе в своем конструкторе для более чистого кода в ваших производных классах и, возможно, в основном автоматизированной сериализации XML.

Для intellisense - ваши производные классы могут иметь реализованные базовые средства доступа с точки зрения ключевого поиска. Intellisense представит эти имена аксессуаров.

Этот подход хорошо сработал для меня - в классическом объектно-ориентированном дизайне есть своего рода близорукость, особенно для больших систем с подключенными компонентами. ИМО, более неуклюжая проверка типов здесь - большая проблема, но гибкость делает ее стоящей.

Этот подход хорошо сработал для меня - в классическом объектно-ориентированном дизайне есть своего рода близорукость, особенно для больших систем с подключенными компонентами. ИМО, более неуклюжая проверка типов здесь - большая проблема, но гибкость делает ее стоящей.

Этот подход хорошо сработал для меня - в классическом объектно-ориентированном дизайне есть своего рода близорукость, особенно для больших систем с подключенными компонентами. ИМО, более неуклюжая проверка типов здесь - большая проблема, но гибкость делает ее стоящей.

Если вы не ограничены взаимодействием с внешней схемой, вам следует использовать сериализацию во время выполнения и SoapFormatter. Шаблон для сериализации во время выполнения позволяет производным классам указывать, какие из их свойств необходимо сериализовать и что с ними делать при десериализации.

Сериализатору XML требуется XmlInclude, потому что, по сути, он должен определить схему для использования.

115566]

С программной точки зрения это звучит так, как будто это может быть работа для шаблона декоратора . По сути, у вас есть суперкласс, который определяет общий интерфейс для всех этих типов устройств. Затем у вас есть классы декораторов, которые имеют другие свойства, которые может иметь устройство. И при создании этих устройств вы можете динамически добавлять эти украшения для определения новых свойств устройства. Графически:

Вы можете посмотреть на страницу Википедии для более подробного описания. После этого нужно будет выполнить некоторую сериализацию, чтобы сообщить программе, какие декораторы загружать.