抽象化チャレンジこの目的のためにカプセル化に近づく方法

Question

ここで使用される悪い習慣にコメントしないでください。私は、このシナリオの抽象化に簡単な例を用いて取り組んでいます。

私は、ユーザーが特定の構成パラメーターでTASKというエンティティーを入力し、後でそのタスクに特有のアクションをTASKに実行させるシステムをモデル化しようとしています。

タスク定義の例を次に示します。
*ディレクトリ{パス}にファイル{ファイル名}を作成します。
*ファイル{filename}を{source directory}から{target directory}にコピーします。
* {メモ帳アプリケーション}を開き、テキスト{サンプルテキスト}を入力して{filename}として保存します。
* {sample.docx}を開き、2番目の段落の最後に{sample text}というテキストを入力します。

各タスクにはわかりやすい名前と最大5つのパラメータがあります。上記の例では、パラメータは中括弧{}で囲まれています。ユーザーは上記のタスクを実行するように指示され、アプリケーションは完了したかどうかを確認します。タスクは実質的に何もすることができ、

public abstract class TaskBase { public abstract void Perform(param1, ... param5); }
public class TaskFileCopy: TaskBase { public override void Perform(param1, ... param5) {} }

問題があり、プログラムの後にコンパイルされ、展開されている：私は次のクラスを作成し、静的な世界では

：各タスクには、以下の機能を持っている必要がありますより多くのタスクを追加する必要があります。最初に、そして最悪のことは、TaskBaseから派生し続け、実行、再コンパイル、再デプロイメントを実装し、以前のタスク結果をそのまま維持することです。

ここでは2つの問題が発生します.2,000個のタスクを実行する頃には、最大2,000個の派生クラスがあり、2番目に、基礎となるOODBが塞がることになります。

私はSystem.AddInをある時点で考えていましたが、このシナリオがOOP設計の中でより良い解決策を持っていると確信しています。

Answer 1

System.AddInがこの種のものに適しているかどうかは疑問です。 IMHO System.AddInは、より静的なAPI用であり、急速に拡張される予定のもの用ではありません。おそらく、あなたはMEFを見ることができますが、それはより簡単で、拡張性と構成に基づいています。

あなたが言うように、2000年の派生クラスを持つことは悪夢になるので、継承もやり方ではありません。

私は、継承の代わりに合成に基づいたデザインパターンを探すべきだと思います。それらのいくつかがあります。それらの1つはCompositeパターンです。このパターンでは、非常に単純な再利用可能なタスクを持つことができ、より複雑なタスクに組み合わせることができます。サブタスク、サブタスク、オンとオンを含むサブタスクを含むタスクを持つことができます。

また、DLRでホストできる動的言語を見ることができます。 IronPythonのように。スクリプトリポジトリを作成することができます。各スクリプトはタスクです。

また、インスピレーションのために、Windows Workflow Foundationと特にアクティビティを見ることができます。

再利用を最大限にする必要があることは明らかです。もちろん、これは簡単なことです。

よろしくお願いいたします。