インターフェイス分離フレームワークとパターン

Question

私はページからテロップデータの束を処理するアプリケーションを書いています。私が扱っている主なクラスは、Instrumentと呼ばれ、どの楽器にも関連するすべてのデータを格納するために使用されます。データはウェブサイトからダウンロードされ、解析されます。

class Instrument 
{ 
    string Ticker {get; set;} 
    InstrumentType Type {get; set;} 
    DateTime LastUpdate {get; set;} 
} 

私の問題は、データの解析を扱うクラスを正しく構造化する方法がわかりません。私は多くの異なるフィールド（Tickers、InstrumentType、Timestampsなど）を埋め込むためにデータを解析する必要があるだけでなく、データがさまざまなソースから取得されるため、解析のすべてを処理する標準パターンはありません。低レベルの解析メソッド（文字列から型/型/タイムスタンプを正規表現し、グループマッチを個別に解析する必要がある場合）を使用する必要がある解析メソッドもあります。

私の最初の試みは、一つの大きなクラスを作成することでしたParsingHandler方法の束は、すべての特定の構文解析ニュアンスに対処し、インストゥルメントクラスにフィールドとしてそれを追加するために含まれているが、私は何回もことがわかった、プロジェクトが進化するにつれて、私はメソッドを追加するか、新しい予期しない状況にクラスを適合させるためのパラメータを追加することを余儀なくされました。

class ParsingHandler 
{ 
     string GetTicker(string haystack); 
     InstrumentType GetType(string haystack); 
     DateTime GetTimestamp(string haystack); 
} 

は、より多くのインターフェイス中心の設計手法を適応しようとした後、私は別のルートを試してみましたが、このインタフェースを定義した：

interface IParser<outParam, inParam> 
{ 
     outParam Parse(inParam data); 
} 

そして、私が対処構文解析クラスの束を定義したインターフェースを使用して、あらゆる特定の構文解析の状況で。たとえば：

class InstrumentTypeParser : IParser<InstrumentType, string> 
{ 
     InstrumentType Parse(string data); 
} 

class RegexMatchParser : IParser<Instrument, Match> where Instrument : class, new() 
{ 
    public RegexMatchParser(
      IParser<string, string> tickerParser, 
      IParser<InstrumentType, string> instrumentParser, 
      IParser<DateTime, string> timestampParser) 
    { 
     // store into private fields 
    } 

    Instrument Parser(Match haystack) 
    { 
      var instrument = new Instrument(); 
      //parse everything 
      return instrument; 
    } 
} 

これは正常に動作するようですが、私は状況に今の私は、私はクラスのコンストラクタに渡す必要があります実装のトンを持っているようにそれはそうでした。それは危険なほど理解できないほどに近いようです。それに対処する私の考えは、特定の解析実装をすべて格納するenumと辞書を定義することですが、私はそれが間違っているか、またはこの細かいアプローチで一般的に間違った方向に向かうことを心配しています。私の方法論は分断されていますか？私が元々持っていたような大量のメソッドを持つ1つの主要な解析クラスを持つ方が良いでしょうか？この特定のタイプの状況のた​​めの代替アプローチがありますか？

Answer 1

私はパーサを一般的なものにしようとすると、IParser<TOut, TIn>とは同意しません。私は、InstrumentParserのようなものは、楽器を扱うのにかなり十分であるように見えます。

とにかく、Matchオブジェクトやそれに類するもののような別のものを解析するときは、一般的な引数を扱う興味深いテクニックを1つ適用することができます。つまり、あなたが解析しているものが分かっている場合（string〜Instrumentのような理由でジェネリックスが存在するのであれば）、にはという一般的な引数はないでしょう。その場合、あなたは特別なインタフェースおよび/または減少した汎用的な引数リストを持つクラスを定義することができます。

interface IStringParser<T>: IParser<T, string> { } 

あなたはおそらく、とにかく文字列からのデータを解析します。その場合、あなたはマッチオブジェクトから解析する汎用クラスを提供することができます繰り返し、この技術を適用することにより

class RegexParser: IStringParser<T> 
{ 
    Regex regex; 
    IParser<T, Match> parser; 

    public RegexParser(Regex regex, IParser<T, Match> containedParser) 
    { 
     this.regex = regex; 
     this.parser = containedParser; 
    } 
    ... 
    T Parse(string data) 
    { 
     return parser.Parse(regex.Match(data)); 
    } 
} 

を、あなたは最上位の消費クラスは唯一の非ジェネリックインターフェイスまたはインターフェイスを持つに依存することができます1人の一般会員。中級クラスは、より複雑な（そしてより具体的な）実装を包み込み、すべてが構成の問題になります。

目標は、常に可能な限り単純な消費クラスに向かうことです。したがって、詳細をラップし、消費者から隠すようにしてください。