c# - ここで抽象クラスまたはインターフェースが必要ですか (またはどちらも必要ありません)?

Question

倉庫を持っています。ボックスの場所を名前、説明、UPC などで検索したい場合があります。これらの各検索メソッドは、同じさまざまなプライベートメソッドを呼び出して、データの検索に役立つ情報を見つけます。

たとえば、upc はプライベートメソッドを呼び出して行 ID を検索します。name も X もそうです。したがって、それらすべてに対してそのメソッドが必要です。その行 ID を使用して、シェルフの場所を見つけることができます (これは単なる例です)。

しかし、私の質問は、さまざまな方法でボックスを検索しているため、抽象クラス (または他の何か) を使用する必要があるかどうかです。

言い換えれば、ルックアップ用の私のコードは、UPC とロケーション用に非常に似ているとします。各メソッドは何かを呼び出すことができます (select * from xxxx where location =、または select * from xxxx where upc =)。同じクラスに 2 つの異なるメソッドを作成することもできます

LocateByUPC(string upc)...
LocateByLocation(string location)...
LocateByDescription(string description)

... 繰り返しますが、これは 1 つの大きなクラスになります。

保持できるスーパークラスが必要な理由はありますか

abstract class MySuper
{

properties...

LocateBox(string mycriteria)...

}

それを継承して、必要なバージョンの LocateBox メソッドをオーバーライドする 2 番目のクラスを作成しますか?

OODに見える以外に、なぜこれをやりたいのかわかりません。これは、正当な理由があれば、これをやりたいということを意味します。しかし、私は利点がないことを知っています。クラスがどんどん大きくなっていくのがわかっただけで、メソッドの名前と少しのコードを少し変更しただけで、継承の方が良いのではないかと思いました。

それが重要な場合はC＃を使用してください。

編集 - ソースがなく、クラス定義が含まれている .dll だけを誰かに渡した場合、これを行いますか? クラス定義。私のプロパティなどと、どのメソッドをオーバーライドするかを教えてくれます。

score 2 · Accepted Answer

ない

抽象クラスもインターフェイスも使用しないと、プロトコルが単純化されません。つまり、 LocateXXX メソッドの束が残ることになります。

一般的な Locate(string criteria) メソッドをベースとして使用し、頻繁に使用することがわかっているメソッドシグネチャのみを定義することをお勧めします。ジェネリックは、必要な場合に備えて、将来の拡張のための包括的なものになる可能性があります (ジェネリックに依存することで、コーディングとテストが簡素化されます)。

score 1 · Accepted Answer

Template Method と呼ばれる設計パターンを実装したいと思われるかもしれません。基本的には、ルックアップアルゴリズムの概要を基本クラスで final メソッドとして定義し、それらのメソッドに共通のコードを配置します。型に応じて異なる動作が必要なメソッドの場合は、基本クラスの最終メソッドが子で保護されたメソッドを呼び出し、各子型がその動作を実装するようにします。

いくつかのリソースをオンラインで見ることができます。テンプレートメソッドデザインパターンを Google 検索してください。うまくいけば、それはあなたの質問に光を当てるでしょう.

score 0 · Accepted Answer

明らかに、ここで多形であるエンティティは制約です。文字列を使用することは同じことを達成するための迅速で汚い方法ですが、型システムは完全にループから外れており、ガベージ文字列の値は意味のある制約仕様と同じように入力に有効です。

それで、

LocateBy (Constraint constraint);

と

abstract class Constraint {
   String toString ();
}

class LocationConstraint extends Constraint { /* ... */}

等

score 0 · Accepted Answer

抽象化は、複数の実装がある場合に役立ちます。そして、将来の保証のために（新しい実装が登場することを願っています）。インターフェイスは、クライアントと実装者の間の契約として機能します。これは不変式です。実装は、必要な数のメソッドを自由に追加できます。そんなニーズはありませんか？

それはあなたの質問に答えるのに役立ちますか?

score 0 · Accepted Answer

あなたが提案しているのは（基本的に）Strategy patternです。ウィキペディアにリンクするのは好きではありませんが、少なくとも始めるには良い場所です。長所と短所を見て、それがあなたにとって有益かどうかを確認してください。

あなたがこのようにする必要は本当にないと思います。LocateBox メソッドを public にして、実行したい検索に基づいて private ヘルパーを呼び出すだけです。オブジェクト指向の設計原則を使用するためだけに、クラス構造を過度に複雑にすることは、一般的には悪い考えです。それらの必要性が見つかるまで待ってから、適切にリファクタリングしてください。これは、本当に必要なものと時間の無駄を指摘するのに役立ちます。

編集：私が考えていた別のアプローチは、検索できるさまざまなものに基づいたプロパティを持つデータクラスを作成することです。すなわち。UPC などのプロパティを持つ BoxSearchData クラスを作成し、それを LocateBox() に渡し、null のプロパティに基づいて必要に応じてクエリを作成します。これは、後で複数の基準で検索を構築するのに役立ちます。

score 0 · Accepted Answer

この例をよく見ると、ルックアップに使用されるプロパティのみが変更されていることがわかります。これを OO の方法で表すと、最終的には「Lookup」と呼ばれるクラスになります (おそらく SQL や別のクエリ言語での検索を表します: 何らかのプロパティに基づいて rowId を返し、検索対象となるオブジェクトです)。その物件の価値。

実際の動作の変化は、クエリ言語にあります。したがって、抽象クラスまたはインターフェースを作成する場合は、その目的を果たす必要があります。プロパティと値の変動の問題は、クエリ呼び出しに「プロパティ」引数を追加することで分離できます。

score 0 · Accepted Answer

私の意見では、それは必要ではないようです。さまざまな検索機能を持つ単一のリポジトリを用意するだけです。あとは、必要なときに必要な機能を使用するだけです。

ただし、インターフェイス部分は、さまざまな種類の検索をキューに入れるツールがある場合にのみ役立ちます。次に、すべてが Interface を実装するさまざまなタイプの Search クラスを作成するファクトリを持つことができます。その時点で、キューに入れられた Search クラスを列挙し、インターフェイスにキャストし、仮想で正しい検索タイプを指す関数を実行できます。例：ReturnDataObject GetItem(object param);

余談ですが、データをプルするときのインターフェースには他の用途があります。それは頭に浮かぶ最初の例にすぎません。

c# - ここで抽象クラスまたはインターフェースが必要ですか (またはどちらも必要ありません)?

8 に答える 8

ない

Related

Reference