メソッドを引数名（型ではなく）で区別するだけで十分ですか？

メソッドを引数名（型ではなく）で区別するだけで十分ですか、それとも明示的に名前を付ける方がよいでしょうか？

たとえば、T Find<T>(int id)VS T FindById<T>(int id)。

ById引数名だけを保持するのではなく、より明示的に名前を付ける（つまり、追加する）正当な理由はありますか？

私が考えることができる理由の1つは、メソッドのシグネチャが同じであるが、意味が異なる場合です。

FindByFirstName(string name) そして FindByLastName(string name)

より明確に名前を付ける正当な理由があります。

主に自明のメソッド定義ではなく、メソッドuseです。しながらfindById(string id)かつfind(string id)自明の両方である、との間に大きな差があるfindById("BOB")とはfind("BOB")。前者の場合、ランダムリテラルは実際にはIDであることがわかります。後者の場合、あなたは確信が持てません-それは実際には与えられた名前か何か他のものであるかもしれません。

FindById（）の利点。

1. 今後の防：あなたが開始した場合はFind(int)、後に、他の方法を追加する必要があります（FindByName(string)、FindByLegacyId(int)、FindByCustomerId(int)、FindByOrderId(int)、など）、私のような人は探している年齢を費やす傾向にあります FindById(int)。可能になり、必要になったら変更するのであれば、実際には問題ではありません。将来の校正は、これらの場合についてです。Find(int)FindById(int)

2. 読みやすい。Find以下のようなコールに見える場合は完全に罰金ですrecord = Find(customerId);けれどもがFindById、それはだ場合読み取るため少し簡単ですrecord = FindById(AFunction());。

3. 一貫性。どこでも一貫してFindByX(int)/ FindByY(int)パターンを適用できますが、Find(int X)/ Find(int Y)は競合するため不可能です。

Find（）の利点

• キッス。Findシンプルでわかりoperator[]やすく、このコンテキストで最も期待される2つの関数名の1つです。（いくつかの人気のある代替はget、コンテキストに応じて、、lookupまたはfetch、です）。
• 経験則として、関数の機能を正確に説明する単一のよく知られた単語である関数名がある場合は、それを使用します。関数が何をするかを説明するのに少し長めの長い複数語の名前がある場合でも。例：Length vs NumberOfElements。トレードオフがあり、どこに線を引くかは継続的な議論の対象です。
• 一般に、冗長性を回避するのが適切です。を見てみるとFindById(int id)、冗長性をに変更することで簡単に冗長性を削除できますFind(int id)が、トレードオフがあります-明確さが失われます。

または、強く型付けされたIDを使用して、両方の利点を得ることができます。

CustomerRecord Find(Id<Customer> id) 
// Or, depending on local coding standards
CustomerRecord Find(CustomerId id) 

実装Id<>：C＃でのID値の厳密な入力

上記のリンクと同様に、ここでのコメントはId<Customer>、私が対処したいことに関して複数の懸念を提起しました：

• 懸念1：ジェネリックの乱用です。 CustomerIdとOrderIDは異なるタイプ（customerId1 = customerId2;=>良い、customerId1 = orderId1;=>悪い）ですが、それらの実装はほぼ同じであるため、コピーペーストまたはメタプログラミングで実装できます。ジェネリックの公開または非表示に関する議論には価値がありますが、メタプログラミングはジェネリックの目的です。
• 懸念2：それは簡単なmistakes./It'sに問題の検索でソリューションを停止しない、強く型付けされたIDを使用することによって除去の主な問題は、への呼び出しで間違った引数の順序ですDoSomething(int customerId, int orderId, int productId)。厳密に型指定されたIDは、OPが尋ねたものを含む他の問題も防ぎます。
• 懸念3：実際にはコードがわかりにくくなっています。idが保持されているかどうかを判断するのは困難int aVariableです。Idがに保持されていることは簡単にわかりId<Customer> aVariableます。また、それが顧客IDであることもわかります。
• 懸念事項4：これらのIDは強力なタイプではなく、単なるラッパーです。 Stringはの単なるラッパーbyte[]です。ラッピングまたはカプセル化は、厳密な型指定と競合しません。
• 懸念事項5：過剰に設計されています。以下に最小バージョンを示しますが、追加することoperator==をお勧めしoperator!=ますが、もしあなただけに依存したくない場合はEquals：

。

public struct Id<T>: {
    private readonly int _value ;
    public Id(int value) { _value = value; }
    public static explicit operator int(Id<T> id) { return id._value; }
}

これについて考えるもう1つの方法は、言語の型安全性を使用することです。

次のようなメソッドを実装できます。

Find(FirstName name);

FirstNameは、ファーストネームを含む文字列をラップする単純なオブジェクトであり、メソッドが何をしているのか、それが呼び出される引数に混乱がないことを意味します。

FindByIDのような明示的な宣言に投票します。変更のためにソフトウェアを構築する必要があります。開いて閉じている必要があります（SOLID）。したがって、このクラスは、FindByNameなどのような同様の検索メソッドを追加するために開かれています。

ただし、FindByIDは閉じられており、その実装は単体テスト済みです。

述語を使用したメソッドは提案しませんが、それらは汎用レベルで優れています。フィールド（ByID）に基づいて、完全に異なる方法論がある場合はどうでしょう。

次のような述語を使用することを誰も提案していないことに驚いています。

User Find(Predicate<User> predicate)

このアプローチでは、APIの表面を縮小するだけでなく、それを使用するユーザーにより多くの制御を提供します。

それだけでは不十分な場合は、いつでもニーズに合わせて拡張できます。