Oopデータ構造のアドバイス

Question

私は、さまざまなファイル構造を読み取ることができるログファイルデコーダを作成しています。私の質問は、このデータをどのように表現するのが最善かです。私はC＃を使用していますが、OOPを初めて使用しています。

例： ログファイルにはセンサー値の範囲があります。 1つのセンサ読み取り値は、A、別のBと呼ぶことができます。明らかに、2つ以上のエントリタイプがあります。 異なるログファイルには、ABABABABABまたはAAAAABBBBBのいずれかとして格納できます。

私はこれをエントリのブロックとして説明していました。したがって、最初のケースでは、ブロックは5ブロックの 'AB'になります。第2の場合、第1のブロックは「A」であり、5回読み取られる。これに続いて 'B'のブロックが続き、5回読み取られます。

これは非常に簡単です（実際には40種類のログファイルがあり、ブロックごとに最大40個のセンサー値があります）。 300以上のブロックを持つログはありません。

現在、私はこのすべてをデータテーブルに保存しています。私は、各エントリのための列を持っています。これを-1に設定すると、ブロック内の次の列に進みます。もしそうでなければ、それはブロックの終わりに達したと仮定する。

これはすべて非常に不器用なようです。誰もこれを行うためのより良い方法を提案することはできますか？

Answer 1

非常に基本的でわかりやすい：

1. がEntryを表し、知っておくべきバイナリシリアル化を行うIEntry
2. コードを実装するクラスを定義しstring EntryBlock, int Count
3. のような特性を持つIEnrtyするためのインターフェイスを定義しますインタフェースは、例えばそれはをオーバーライドすることができIEnumerable<IEntry>
4. クラスEntryをreffer必要がありますは、あなたがより多くの情報が必要な場合は、[ABABは-2]、これは直列化しながら、参考になるで確実場合
5. インタフェースIEntryそれが参考になる場合は、メソッドのボイドCreateFromRawString(string rawDataFromLog)を提供することができ、自分

を決めるような何かをしてください戻します

Answer 2

まず、here,を起動してからhereを起動して、オブジェクト指向プログラミングについて少し学んでください。 OOPについて学んでいる間にあなたの現在の問題について心配しないでください。

OOの概念について学んでいるので、コードはデータではなく、データはコードではないことを理解しておく必要があります。 OOPの立場からデータをどのように表現するかは関係ありません。データを消費するOOコードを書くことができます。また、データのフォーマットに関係のないデータを消費するための手続き型コードを書くこともできます。その後、あなたの質問に戻ってき

だから

私の質問は最高のそれはあなたのニーズに依存し、このデータ

を表現する方法です。ログファイルの内容は何ですか？あなたは作家と読者を支配していますか？私がした場合、私は書く必要があるコードの量を最小化するために組み込まれたserializationメソッドを頼りにしています。ログファイルは本当に長くなるでしょうか？もしそうなら、あなたが記述した "データテーブル"のアプローチが通常より良いです。ログファイルのファイルサイズが大きくならない場合、XMLは本当に扱いやすいです。

Answer 3

OOPに関しては、SOLIDを学びたいと思っています。

テスト駆動型開発を使用してこれを構築することをお勧めします。

[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を返すようモックを設定します。

Answer 4

ボブが提供したものに加えて、私は非常にC＃のプログラマのためのOOに優しいが、強力な導入としてHead First Design Patternsをお勧めします。サンプルはJavaになっており、C＃に簡単に変換できます。