このような場合に必要な最小限のデータを常に関数に渡す必要があります

IsAdminユーザーが管理者であるかどうかをチェックする機能があるとしましょう。また、管理者チェックは、ユーザーID、名前、およびパスワードを何らかのルール（重要ではない）と照合することで行われるとしましょう。

私の頭の中には、このための2つの可能な関数シグネチャがあります。

public bool IsAdmin(User user);
public bool IsAdmin(int id, string name, string password);

私は次のことを考えて、ほとんどの場合、2番目のタイプの署名を使用します。

• 関数の署名は、読者により多くの情報を提供します
• 関数内に含まれるロジックは、Userクラスについて知る必要はありません
• 通常、関数内のコードはわずかに少なくなります

しかし、私は時々このアプローチに疑問を呈し、またある時点でそれが扱いにくくなることを認識しています。たとえば、関数が10個の異なるオブジェクトフィールド間を結果boolにマップする場合、私は明らかにオブジェクト全体を送信します。しかし、そのような厳格な例は別として、実際のオブジェクトを渡す理由がわかりません。

どちらのスタイルについても議論があれば、また一般的な意見をいただければ幸いです。

私はオブジェクト指向スタイルと機能スタイルの両方でプログラミングしているので、質問はありとあらゆるイディオムに関するものと見なされるべきです。

私は個人的にちょうど最初の方法を好む IsAdmin(User user)

使いやすく、IsAdminの基準が後日（おそらくロールまたはisActiveに基づいて）変更される場合、メソッドシグネチャをどこでも書き換える必要はありません。

また、ユーザーが管理者であるかどうかを決定するプロパティを宣伝したり、あらゆる場所でパスワードプロパティを渡したりしないので、おそらくより安全です。そして、シリオンは、あなたidがname/にマッチしないときに何が起こるかという良いポイントを作りますpassword。

メソッド内のコードの長さは、メソッドが機能する限り、実際には問題ではありません。ヘルパーメソッドコードよりも短くてシンプルなアプリケーションコードが必要です。

最初の署名は、Userオブジェクト自体にユーザー関連のロジックをカプセル化できるため、優れています。コードベースについてばらまかれる「id、name、password」タプルの構築のためのロジックを持つことは有益ではありません。さらに、isAdmin関数が複雑になります。たとえば、にid一致しないを渡すとnameどうなりますか？特定のユーザーが、パスワードを知らないコンテキストの管理者であるかどうかを確認したい場合はどうしますか？

さらに、追加の引数を指定したスタイルを支持する3番目のポイントに関するメモとして。「関数内のコードが少なくなります」が、そのロジックはどこに行くのでしょうか？ただ消えることはできません！代わりに、関数が呼び出されるすべての場所に広がります。1つの場所に5行のコードを保存するには、関数の使用ごとに5行を支払いました。

最初の、しかし、他の人が与えた理由のためだけではありません。

public bool IsAdmin(User user);

これはタイプセーフです。特にUserは自分で定義した型なので、引数を転置したり切り替えたりする機会はほとんど、またはまったくありません。これは明らかにユーザーに対して機能し、intおよび2つの文字列を受け入れる汎用関数ではありません。これは、コードのように見えるJavaやC＃のようなタイプセーフな言語を使用するポイントの大きな部分です。特定の言語について質問している場合、その言語のタグを質問に追加できます。

public bool IsAdmin(int id, string name, string password);

ここでは、intと2つの文字列で対応します。名前とパスワードを転置できないのは何ですか？2番目の方法は、使用する作業が多く、エラーが発生する可能性が高くなります。

おそらく、両方の関数は、関数内（最初の場合）または関数を呼び出す前（2番目）にuser.getId（）、user.getName（）、およびuser.getPassword（）を呼び出す必要があるため、結合の量はどちらの方法でも同じです。実際、この関数はユーザーでのみ有効であるため、Javaではすべての引数を削除し、これをユーザーオブジェクトのインスタンスメソッドにします。

user.isAdmin();

この関数は既にユーザーと密接に結合されているため、ユーザーの一部に含めることは理にかなっています。

PSこれは単なる例に過ぎないはずですが、パスワードを保存しているようです。代わりに、暗号で保護されたパスワードハッシュのみを保存する必要があります。ログイン時に、指定されたパスワードは同じ方法でハッシュされ、保存されたハッシュと比較されます。平文でパスワードを送信することは避けてください。このルールに違反し、isAdmin（int Str Str）がユーザー名をログに記録し、コードで名前とパスワードを置き換えた場合、代わりにパスワードがログに記録される可能性があり、セキュリティ上の問題が発生します（ログにパスワードを書き込まないでください） ）そして、コンポーネントの代わりにオブジェクトを渡す（またはクラスメソッドを使用する）ことを支持する別の引数です。

選択した言語が値による構造を渡さない場合、(User user)バリアントはより良いようです。いつかユーザー名を破棄し、ID /パスワードを使用してユーザーを識別することにした場合はどうなりますか？

また、このアプローチは必然的に、長くて誇張されたメソッド呼び出し、または不整合につながります。3つの引数を渡しても大丈夫ですか？5はどうですか？または6？オブジェクトの受け渡しがリソースの点で安価な場合（おそらく3つの引数を渡すよりもさらに安い場合）、なぜそれを考えるのでしょうか？

そして、2番目のアプローチが読者にもっと情報を提供することに同意します-直感的に、メソッド呼び出しは「与えられたID /名前/パスワードの組み合わせに管理者権限があるかどうか」ではなく「ユーザーに管理者権限があるかどうか」を尋ねています。

したがって、Userオブジェクトを渡すと大きな構造がコピーされない限り、最初のアプローチはよりクリーンで論理的です。

私はおそらく両方を持っているでしょう。外部APIとしての最初のものであり、ある程度の安定性が期待されています。2番目は、外部APIによって呼び出されるプライベート実装です。

後でチェックルールを変更する必要がある場合は、外部から呼び出された新しい署名を使用して新しいプライベート関数を記述するだけです。

これには、内部実装を簡単に変更できるという利点があります。また、両方の機能を同時に使用可能にし、外部コンテキストの変更に応じてどちらか一方を呼び出す必要がある場合もあります（たとえば、異なるフィールドを持つ古いユーザーと新しいユーザーが共存する場合があります）。

質問のタイトルに関しては、どちらの場合も、最低限必要な情報を提供しています。ユーザーは、情報を含む最小のアプリケーション関連データ構造のようです。id、password、nameの3つのフィールドは、実際に必要な最小の実装データのようですが、実際にはアプリケーションレベルのオブジェクトではありません。

言い換えれば、データベースを扱っている場合、ユーザーはレコードになり、ID、パスワード、およびログインはそのレコードのフィールドになります。

クラス（参照型）をメソッドに送信することには1つのマイナス点があります。それは、Mass-Assignment Vulnerabilityです。IsAdmin(User user)メソッドの代わりにメソッドがあると想像してくださいUpdateUser(User user)。

場合はUser、クラスと呼ばれるブール型プロパティを持っているIsAdmin、と私は私のメソッドの実行中にそれをチェックしない場合、私は大量の割り当てに対して脆弱です。GitHubは、2012年にこのまさに署名によって攻撃されました。

私はこのアプローチで行きます：

public bool IsAdmin(this IUser user) { /* ... */ }

public class User: IUser { /* ... */ }

public interface IUser
{
    string Username {get;}
    string Password {get;}
    IID Id {get;}
}

• インターフェイスタイプをこの関数のパラメーターとして使用すると、ユーザーオブジェクトを渡して、テスト用の模擬ユーザーオブジェクトを定義でき、この関数の使用と保守の両方に関して柔軟性が高まります。

• this関数をすべてのIUserクラスの拡張メソッドにするためのキーワードも追加しました。この方法により、よりオブジェクト指向の方法でコードを記述し、Linqクエリでこの関数を使用できます。それでも、IUserとUserでこの関数を定義する方が簡単ですが、このメソッドをそのクラスの外部に配置することに決めた理由があると思いますか？

• IDのプロパティを再定義できるため、IID代わりにカスタムインターフェイスを使用しintます。例えば、あなたは今までから変更する必要があるのintに対してlong、Guidまたは何か他のもの。それはおそらくやり過ぎですが、初期の決定に縛られないように物事を柔軟にしようとすることは常に良いことです。

• 注意：IUserオブジェクトは、異なる名前空間やUserクラスのアセンブリにある可能性があるため、ユーザーコードとIsAdminコードを完全に分離して、1つの参照ライブラリのみを共有するオプションがあります。まさにあなたがそこで行うことは、これらのアイテムがどのように使用されるのかを疑うための呼び出しです。

免責事項：

返信では、スタイルの問題に焦点を当て、セキュリティの観点から、ID、ログイン、およびプレーンパスワードが使用する適切なパラメーターセットであるかどうかを忘れます。ユーザーの特権について把握するために使用している基本的なデータセットに対する私の答えを推定できるはずです...

またuser.isAdmin()、と同等であると考えIsAdmin(User user)ます。それはあなたが選ぶべき選択です。

応答：

私の推奨事項は、どちらかのユーザーのみです。

public bool IsAdmin(User user);

または、次の行に沿って両方を使用します。

public bool IsAdmin(User user); // calls the private method below
private bool IsAdmin(int id, string name, string password);

パブリックメソッドの理由：

パブリックメソッドを記述するときは、通常、それらがどのように使用されるかを考えるのが良いでしょう。

この特定のケースでは、通常このメソッドを呼び出す理由は、特定のユーザーが管理者であるかどうかを把握するためです。それはあなたが必要とする方法です。各呼び出し元が送信する適切なパラメーターを選択する必要はありません（コードの重複によるミスのリスクもあります）。

プライベートメソッドの理由：

必要なパラメーターの最小セットのみを受け取るプライベートメソッドは、良いことです。時々そんなにありません。

これらのメソッドを分割する利点の1つは、同じクラスの複数のパブリックメソッドからプライベートバージョンを呼び出すことができることです。あなたがのためにわずかに異なるロジックを持つように（何らかの理由で）をしたかった場合例えばLocaluserとRemoteUser（？多分、リモート管理者をオン/オフにする設定があります）：

public bool IsAdmin(Localuser user); // Just call private method
public bool IsAdmin(RemoteUser user); // Check if setting is on, then call private method
private bool IsAdmin(int id, string name, string password);

さらに、何らかの理由でprivateメソッドをpublicにする必要がある場合は...できます。に変更privateするのと同じくらい簡単publicです。この場合、それほど大きな利点とは思えないかもしれませんが、実際にはそうなる場合があります。

また、単体テストを行うと、よりアトミックなテストを行うことができます。通常、このメソッドでテストを実行するために完全なユーザーオブジェクトを作成する必要がないのは非常に便利です。また、完全なカバレッジが必要な場合は、両方の通話をテストできます。

public bool IsAdmin(int id, string name, string password);

リストされた理由により悪い。それは意味しません

public bool IsAdmin(User user);

自動的に良好です。：特に、ユーザーは、のようなメソッドを持つオブジェクトである場合getOrders()、getFriends()、getAdresses()、...

ID、名前、パスワードのみを含むUserCredentialsタイプでドメインをリファクタリングし、不要なユーザーデータすべてではなくIsAdminに渡すことを検討することもできます。