メソッドパラメータとパラメータオブジェクト

Question

私は、インターフェイスを実装することによって人々が私たちのコア機能を拡張できるようにするフレームワークを構築しようとしています。以下は、このインターフェイスの下の例です。

public interface MyInterface 
{ 
    IData GetData(string p1, char p2, double p3); 
} 

最近、我々は（私は依存のコードを壊すべきではありません知っているが、真実は、我々はまだこのインタフェースを実装する任意のサードパーティを持っていないので、我々はチャンスを持って、このインターフェイスを変更することを決定しましたこのインタフェースを正しく実装するための "do-over"）。

ソフトウェアが正常に動作するためには、このインターフェイスに2つ以上のパラメータを追加する必要があります。私たちが考えている二つの方法は、ちょうどこのような署名に追加されます。

public interface MyInterface 
{ 
    IData GetData(string p1, char p2, double p3, bool p4, DateTime p5); 
} 

またはこの

public class MyParameters 
{ 
    public bool p4 { get; set; } 
    public DateTime p5 { get; set; } 
} 

などのようなメソッドの最後に追加するようにパラメータオブジェクトを作成することによって、 ：

public interface MyInterface 
{ 
    IData GetData(string p1, char p2, double p3, MyParameters p4); 
} 

私はどのような方法で進むべき最も正しい方法であるかに関するある種の指針を探しています。私は両方のカテゴリーで賛否両論を見ることができますが、私の偏見が私を間違った方向に導いてくれることを望んでいません。

私の主な懸念事項は以下のとおりです。ソフトウェアの

• 拡張性 - 私は、ユーザーが
• 保守インタフェースを実装することで、私はまだ考えていないことを行うことができるようにしたい - 理想的には、私は
• クリーンAPI再びのGetData（）を呼び出すための責任があるコードタッチする必要はありませんしたいと思います - サードパーティの開発者はうんざり、私は私が作ることに到着するソリューションを望んでいないが

私はこの問題の指針を得るためにオンラインで質問するのにどのような質問があるか分かりません。私は、答えが「それは依存している」（p1-p5がGetData（）関数の目的にどのように関係しているかなど）、誰かが私が評価するのを助けるために質問しなければならない質問のリストを指し示すことができる1つのソリューションが他のソリューションより優れているかどうか

関連：Post 1 Post 2

Answer 1

私はこれに答えてみましょう。のは、あなたのオプションを評価してみましょう：

a）は、その後、あなたはそれを書き換えるために実装を強制する必要があり、全く使用しないでください。

1）場合は、以下のインタフェース

public interface MyInterface 
{ 
    IData GetData(string p1, char p2, double p3); 
} 

が壊れています。メソッドの定義を変更してください。

public interface MyInterface 
{ 
    IData GetData(something else); 
} 

B）が、あなただけの、あなたが最初のものは廃止され、それらを伝える新しいオーバーロードを作成することができ、新しい定義を使用するユーザーを奨励する必要があります。組み合わせた場合

あなたの新しい定義について

public interface MyInterface 
{ 
    //xml to tell them this is deprecated. 
    IData GetData(string p1, char p2, double p3); 
    IData GetData(string p1, char p2, double p3, and whatever); 
} 

は、誰もがモデルについて知らなくても与えることができます誰もワンストップソリューションありませんが、あなたは自問し、

I）は、「はパラメータ自体は単一のエンティティを表すことができあなたのパラメータを1単位にすることは、実際には何かを意味していますか？ "もしそうなら、そうしてください。そうでない場合は、しないでください。私はあなたがこの種のジレンマにいるときの抽象的なレベルで考えることに頼るべきだと思います。私はクラブのポイントが何であるか分かりませんbool p4とDateTime p5。あなたは、実生活で何かを表現するそれらのパラメータを守るべきです。それらの組み合わせが意味をなさない場合は、そのままにしておきます。あなたは、そのような論理的な考え方にそのようなクラブを残すことで、より多くの成功を収めます。あなたは他のプログラマーにあなたの定義を残していて、仕事を簡単にするために、メソッドの署名は非常に論理的でなければなりません。

II）クラスは単にデータセットを保持するのではなく、もっと多くのことを行うことができますか？クラスはここでオプションにする必要があります。

3）私はクラス定義のみを制御する必要がありますが、実装するのではありません？その場合は、入力の公開インタフェースを定義し、その実装を顧客に任せてください。

IV）今後のインターフェイスの変更は、既存の実装を破ることはできませんか？オーバーロードはあなたの方法です。

あなたは2つの選択肢があり、署名を平らにしたままにしたり、クラブに残しておきます。

1）クラブなし：

a）コードが少なく、別のレイヤーが少なくなりました。

b）別のクラスを公開する必要はありません。ばちで

2）：

a）は関数に行くには、モデルのより良い理解を与える - あなたの意図は明らかです。

b）新しく形成されたクラスを構築するためのオプションの詳細を追加する必要がある場合、将来的には容易に拡張できます。あなたは今、あなたはBOOLや日時などのオプションの詳細を追加したい場合がありますクラス

class Input { 
    string p1; char p2; double p3; 

    public Input(string p1, char p2, double p3){ 
    } 
} 

とインタフェース

public interface MyInterface 
{ 
    IData GetData(Input p1); 
} 

を考えてみましょう。彼らはオプションなので、コンストラクタをintにする必要はありません。それでも同じコンストラクタを持つことができ、コンストラクタの外で必要に応じて変更する権限をユーザに与えます。

class Input { 
    string p1; char p2; double p3; bool p4; DateTime p5; 

    public Input(string p1, char p2, double p3){ 
    } 
} 

インターフェイスは同じでもかまいません。私が言ったように、この種のものを派生させる勢いはあなたのモデルに悲しげに依存しています。要するに、グループ化が何かを意味することができれば、それをクラスまたはインターフェースにする（誰がロジックを制御するかに依存する）。

Answer 2

はなぜすべての道を行くではないが：

public Interface IParameters 
{ 
    string p1 {get; set;} 
    char p2 {get; set;} 
    double p3 {get; set;} 
    bool p4 { get; set; } 
    DateTime p5 { get; set; } 
} 

public interface MyInterface 
{ 
    IData GetData(IParameters p); 
}