1

アルゴリズムに与えられた 2 つの引数に依存する分類 (文字列) のリストを返すアルゴリズムがあります。型変数と、特定の特別な分類を結果リストに追加できるようにする追加のカテゴリ文字列です。

現在の実装は、ルールが if や switch ステートメントとして表現されているため、判読できず、拡張もできません。また、ルールはハードコーディングされています。

コードの簡略版:

 private static List<string> DetermineTypes(Type x, object category) {
  List<string> Types = new List<string>();


  if (category is DateTime) {
    types.Add("1");
    types.Add("2");
    types.Add("3");
  } else if (category is string) {
    switch ((string)category) {
      case "A":
        Types.Add("4");
        break;
      case "B":
      case "C":
      case "D":
        Types.Add("5");
        break;
      case "":
        Types = DetermineTypesFromX(Types, x);
        break;
      default:
        Types.Add("6");
        break;
    }
  }
  return graphTypes;
}


private static List<string> DetermineTypesFromX(List<string> Types, Type x) {
  if (x.Equals(typeof(int))) {
    Types.Add("7");
  } else if (x.Equals(typeof(double))) {
    Types.Add("8");

  } else if (x.Equals(typeof(System.DateTime))) {
    Types.Add("9");
    Types.Add("10");
  }
  return Types;
}

これらを xml で指定するとよいのではないかと考えていたので、新しいタイプやルールにコードの変更を加える必要はありませんでしたが、この状況ではおそらく重すぎます。基本的に、新しい「タイプ」がいつでも追加される可能性があるという問題を解決しようとしています。一般的なケースは、それが上記の「ルール」の 1 つであり、新しい「ルール」ブランチが必要になる可能性が低いエッジケースです。追加されます。

エッジケースが発生する可能性やビジネス環境（スケジュールなど）と比較して、xml定義のルール（またはその他の方法）を使用して完全に動的にするために必要な作業が価値があるかどうかを判断する必要があります。

しかし、質問の主なポイントは、上記のネストされた条件付きコードをどのようにエレガントに単純化できるかということです。スケーラビリティを向上させるために、設計により多くの柔軟性を組み込むことはできますか?

F# のパターン マッチングを組み合わせて使用​​することが適切な解決策になるのではないかと考えていました。(注: F# を使用したことがなく、最近興味があったので、質問しています)

4

6 に答える 6

1

構成ベースのオプションをためらうことはありません。通常、再構築を必要としないという利点があります。それが望ましくない場合は、別のオプションとして、属性を介した type-metadata が考えられます。これにより、新しいタイプ（作成したもの）のデータを追加するのが簡単になり、（間接的に）既存のタイプ（intなど）に属性を追加できます-それらを再び取得するためにTypeDescriptor.AddAttributes使用する限り;-pTypeDescriptor.GetAttributes

これが良いアイデアであるかどうかにかかわらず...まあ、リフレクション（およびツインTypeDescriptor）は遅くなる可能性があるため、これをタイトループで使用したい場合は、まず辞書を含むものを調べます.

于 2009-12-09T05:27:34.120 に答える
1

ディスパッチ テーブルとして知られるパターンは、次の 2 つのブログ投稿で最近説明されており、おそらく興味があるでしょう。

アーロン・フェン

K・スコット・アレン

于 2009-12-09T03:58:39.240 に答える
1

あなたの問題は、決定木または決定表の観点からコーディングされる場合があります

また、決定木に関する Chris Smith のブログへの投稿もあります。

Awesome F# - 決定木 - パート Iおよび Awesome F# - 決定木 - パート II

于 2009-12-09T11:42:21.557 に答える
0

F＃について言及しているので、C＃コードと非常によく似た動作をするF＃コードを次に示します。

open System

let DetermineTypesFromX(x:Type) =
    if x.Equals(typeof<int>) then
        ["7"]
    elif x.Equals(typeof<double>) then
        ["8"]
    elif x.Equals(typeof<DateTime>) then
        ["9"; "10"]
    else
        []

let DetermineTypes(x:Type, category:obj) =
    match category with
    | :? DateTime -> ["1"; "2"; "3"]
    | :? string as s ->
        match s with
        | "A" -> ["4"]
        | "B" | "C" | "D" -> ["5"]
        | "" -> DetermineTypesFromX(x)
        | _ -> ["6"]
    | _ -> []

とはいえ、ロジックをコードから構成ファイルに移動するかどうかに関係なく、ハードコードされたif/switchロジックの代わりにテーブル駆動型アプローチを検討することをお勧めします。

于 2009-12-09T06:20:23.410 に答える
0

私は同様の状況に遭遇し、あなたを助けるかもしれない同様の問題に関して以前にいくつかの質問をしました.

私が行ったシステムは、構成主導型のルールベースの動的システムでした。すべての構成とルールがデータベースに保存されました。デシジョン テーブルは、データベースから取得した値とルールに基づいて動的に構築されました。次に、C# で値を変換して比較しました。これは、C# の動的デシジョン テーブルについて私が尋ねた質問です。そして、データベースから取得した値を動的に変換して比較することに関する質問。

したがって、構成テーブルに関してこれに似たものを持つことになります(単なる例):

Conditions  IsDecision LHS        Operator  RHS
TTFF        False      PostCode   >         100
TFTF        False      PostCode   <         10000
FTTT        True 

Note: LHS is the property name of the object.

平易な英語の上記の表:

Condition 1 PostCode > 100      Yes Yes No  No
Condition 2 PostCode < 10000    Yes No  Yes No
Outcome 1                       Yes
Outcome 2                           Yes
Outcome 3                               Yes
Outcome 4                                   Yes

Then you have other tables/configs to determine the action for each outcome.

実装のコア部分は、意思決定表を動的に構築する方法と、文字列値を動的に変換して比較する方法です。これらはすべて、上記の段落で特定の実装へのリンクを提供しています。あなたの状況に同様の概念を適用できると思います。一般的な概念を説明したことを願っています。

その他のリソース:

Martin Fowler のディシジョン ツリーの記事。

決定木に関するルークの投稿。

于 2009-12-10T04:55:34.333 に答える
0

ビジネスルール/推論エンジンを検討することをお勧めします。NxBRE には優れたコミュニティがあり、かなり成熟しています。これは当面の要件を超える場合がありますが、これらのルールが時間の経過とともに複雑になると予想される場合、BRE は物事を制御するための優れたフレームワークを提供します。

于 2009-12-09T04:39:19.310 に答える