CODEWITHSUNDEEP
c#oopdata-structuresooad
Mark
Mark

Reputation: 1799

Oop data structure advice

I am writing a log file decoder which should be capable of reading many different structures of files. My question is how best to represent this data. I am using C#, but am new to OOP.

An example: The log files have a range of sensor values. One sensor reading can be called A, another B. Obviously, there are many more than 2 entry types. In different log files, they could be stored either as ABABABABAB or AAAAABBBBB.

I was thinking of describing this as blocks of entries. So in the first case, a block would be 'AB', with 5 blocks. In the second case, the first block is 'A', read 5 times. This is followed by a block of 'B', read 5 times.

This is quite a simplification (there are actually 40 different types of log file, each with up to 40 sensor values in a block). No log has more than 300 blocks.

At the moment, I store all of this in a datatable. I have a column for each entry, with a property of how many to read. If this is set to -1, it continues to the next column in the block. If not, it will assume that it has reached the end of the block.

This all seems quite clumsy. Can anyone suggest a better way of doing this?

Upvotes: 0

Views: 376

Answers (4)

sll
sll

Reputation: 62504

Very basic and straightforward:

  1. Define an interface for IEnrty with properties like string EntryBlock, int Count
  2. Define a class which represents an Entry and implements IEntry
  3. Code which doing a binary serialization should be aware of interfaces, for instance it should reffer IEnumerable<IEntry>
  4. Class Entry could override ToString() to return something like [ABAB-2], surely if this is would be helpful whilst serialization
  5. Interface IEntry could provide method void CreateFromRawString(string rawDataFromLog) if it would be helpful, decide yourself

If you want more info please share code you are using for serialization/deserializaton

Upvotes: 0

Brett Veenstra
Brett Veenstra

Reputation: 48464

As for OOP, you want to learn SOLID.

I would suggest you build this using Test Driven Development.

Start small, with a simple fragment of your log data and write a test like (you'll find a better way to do this with experience and apply it to your situation):

[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]);
}

That test code snippet is just a starting point, and I've tried to be rather verbose in the assertions. You can come up with more creative ways over time. The point is to start small. Once this test passes, add another test where you mix "AB" and change your decoder to handle this properly. Eventually, you'll have a large set of tests that handle your different formats. Using TDD, you'll be on the path to using SOLID properly. Whenever you find something you can't test, you should review the rules and see if you can't make it simpler and inject dependencies.

Eventually you'll get into mocking. For example, you might find that you'd rather INJECT the ability for your MyFileDecoder class to have a dependency that will read your log file. In that case, you would create a mock object and pass that into the constructor and set the mock to return the sequenceStub when a method is called.

Upvotes: 0

Eric Farr
Eric Farr

Reputation: 2713

In addition to what Bob has offered, I highly recommend Head First Design Patterns as a gentle, but robust introduction to OO for a C# programmer. The samples are in Java, which translate easily to C#.

Upvotes: 0

Bob
Bob

Reputation: 99704

I think you should first start here, and then here to learn a little bit about what object oriented programming is. Don't worry about your current problem while learning about OOP.

As you are learning about OO concepts, you should begin to understand code is not data, and data is not code. It does not matter how you represent your data from an OOP stance. You can write OO code to consume your data, or you could write procedurage code to consume your data, that part is irrelevant to the format of the data.

So then getting back to your question

My question is how best to represent this data

It depends on your needs. What is writing the log file? Do you have control over the writer and reader? If I did I would rely on build the built in serialization methods to minize the amount of code I need to write. Is the log file going to be really long? If so the "datatable" approach you described is usually better. If the log file isn't going to be a huge in file size, XML is really easy to work with.

Upvotes: 1

Related Questions