Консультации по структуре данных - PullRequest
0 голосов
/ 20 июля 2011

Я пишу декодер файла журнала, который должен быть способен читать множество различных структур файлов.Мой вопрос заключается в том, как лучше представить эти данные.Я использую C #, но я новичок в ООП.

Пример: В файлах журналов есть диапазон значений датчика.Одно показание датчика можно назвать A , другое B .Очевидно, что существует более двух типов записей.В разных лог-файлах они могут храниться как ABABABABAB или AAAAABBBBB.

Я думал описать это как блоки записей.Таким образом, в первом случае блоком будет «AB» с 5 блоками.Во втором случае первый блок «А», прочитанный 5 раз.Затем следует блок «B», который читается 5 раз.

Это довольно упрощение (фактически существует 40 различных типов файлов журнала, каждый из которых содержит до 40 значений датчика в блоке).Ни в одном журнале нет более 300 блоков.

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

Все это выглядит довольно неуклюжим.Кто-нибудь может предложить лучший способ сделать это?

Ответы [ 4 ]

1 голос
/ 20 июля 2011

Я думаю, вы должны сначала начать здесь, , а затем здесь , чтобы немного узнать о том, что такое объектно-ориентированное программирование.Не волнуйтесь о своей текущей проблеме, изучая ООП.

Когда вы изучаете концепции ОО, вы должны начать понимать, что код - это не данные, а данные - это не код.Неважно, как вы представляете свои данные с позиции ООП.Вы можете написать OO-код для использования ваших данных, или вы можете написать процедурный код для использования ваших данных, эта часть не имеет отношения к формату данных.

Итак, вернемся к вашему вопросу

Мой вопрос: как лучше всего представить эти данные

Это зависит от ваших потребностей.Что пишет файл журнала?У вас есть контроль над писателем и читателем?Если бы я это сделал, я бы использовал встроенные методы serialization , чтобы минимизировать объем кода, который мне нужно написать.Файл журнала будет очень длинным?Если так, то описанный вами подход, основанный на данных, обычно лучше.Если файл журнала не будет огромным по размеру, с XML действительно легко работать.

0 голосов
/ 20 июля 2011

Очень простой и понятный:

  1. Определить интерфейс для IEnrty со свойствами, такими как string EntryBlock, int Count
  2. Определить класс, который представляет Entry и реализует IEntry
  3. Код, который выполняет двоичную сериализацию, должен знать интерфейсы, например, он должен указывать IEnumerable<IEntry>
  4. Класс Entry может переопределить ToString(), чтобы вернуть что-то вроде [ABAB-2], конечно, если это будет полезно при сериализации
  5. Интерфейс IEntry может предоставить метод void CreateFromRawString(string rawDataFromLog), если это будет полезно, решите сами

Если вы хотите больше информации, пожалуйста, поделитесь кодом, который вы используете для сериализации / десериализации

0 голосов
/ 20 июля 2011

В дополнение к тому, что предложил Боб, я настоятельно рекомендую Шаблоны проектирования Head First в качестве мягкого, но надежного введения в OO для программиста на C #.Примеры на Java, которые легко переводятся на C #.

0 голосов
/ 20 июля 2011

Что касается ООП, вы хотите изучить SOLID .

Я бы посоветовал вам сделать это с помощью Test Driven Development.

Начните с малого, с простого фрагмента данных вашего журнала и напишите тест вроде: (вы найдете лучший способ сделать это с опытом и применить его к вашей ситуации):

[Test]
public void ReadSequence_FiveA_ReturnsProperList()
{
  // Arrange
    string sequenceStub = "AAAAA";

    // Act
    MyFileDecoder decoder = new MyFileDecoder();
    List<string> results = decoder.ReadSequence(sequenceStub);

    // Assert
    Assert.AreEqual(5, results.Count);
    Assert.AreEqual("A", results[0]);
}

Этот фрагмент тестового кода является лишь отправной точкой, и я пытался быть довольно многословным в утверждениях. Вы можете придумать более креативные способы со временем. Дело в том, чтобы начать с малого. После того, как этот тест пройден, добавьте еще один тест, в котором вы смешаете «AB» и измените свой декодер для правильной обработки. В конце концов, у вас будет большой набор тестов, которые обрабатывают ваши различные форматы. Используя TDD, вы будете на пути к правильному использованию SOLID. Всякий раз, когда вы находите что-то, что не можете протестировать, вы должны пересмотреть правила и посмотреть, не можете ли вы сделать это проще и внедрить зависимости.

В конце концов вы начнете насмехаться. Например, вы можете обнаружить, что вы предпочитаете ВСТАВИТЬ способность вашего класса MyFileDecoder иметь зависимость, которая будет читать ваш файл журнала. В этом случае вы создадите фиктивный объект и передадите его в конструктор, а затем установите макет для возврата sequenceStub при вызове метода.

...