0

ファイルエクスポーターがあり、フィールドタイプを文字列、日付など+各行のフィールド数として検証します。

ここで、csv の作成を担当するクラスがジェネリックであり、ビジネス ロジックから切り離され、ビジネス ニーズが変化した場合にエクスポートされたクラスを修正する必要がないように、そのようなロジックのルールをどこに保持しますか。

ビジネスロジックに使用される2番目のクラスを作成することについては考えていましたが、それには次のものが必要です-どちらも同じように悪いと思います:

  • クラス内のハードコーディングされたルール
  • コンストラクタに渡すルール

良い解決策があるようですが、これはよくある問題でしょうか?

4

2 に答える 2

0

私の意見では、一連の責任パターンを試す必要があります。クライアントは、パラメーターとして渡されたコンテンツが「有効」である場合に true を返すメソッド (つまり、検証) を持つ Validator インターフェイスを実現する Validator オブジェクトのリストを所有します。各コンポーネントには独自の検証基準がありますが、汎用インターフェイスを介してそれを使用するクライアントにはブラックボックス化されています。したがって、システムを構築するときは、クライアントをインスタンス化し、必要なバリデータを挿入します。

于 2012-08-26T12:51:07.483 に答える
0

いつものようにそれは依存します..

データの責任はプロバイダーにあります。前述の「fileExporter」はファイルをエクスポートします。データ プロバイダーが封印されている場合は、明らかにデータをアサートするバリデーターを作成し、その後、アサートされたデータがファイル エクスポーターに渡されます。

封印されていない場合は、依存関係を注入できます。

すなわち

class DataProvider(IDataValidator dataValidator, IFileFormat fileFormat){...}
interface IFileFormat { void Export();}
interface IDataValidator { void AsserData(); }
class CSVDataValidator : IDataValidator{...}
class CSVFileExporter : IFileExporter {..}

var dataValidator = new CSVDataValidator();
var iFileFormat = new CSVFileFormat();
var dataProvider = new DataProvider(dataValidator, fileFormat);
var data = dataProvider.Data;
var csvFileExporter = new CSVFileExporter(data)
csvFileExporter.Export();

基本的に可能性は無限です。それは、何を閉じたいか、何を将来拡張したいかによって異なります。

私は戦略/依存性注入/オープンクローズ原則を読みます

于 2012-08-26T12:11:39.730 に答える