C＃のis演算子とJavaのinstanceof演算子を使用すると、オブジェクトインスタンスが実装しているインターフェイス（または、より基本的にはその基本クラス）で分岐できます。

インターフェイスが提供する機能に基づいた高レベルの分岐にこの機能を使用することは適切ですか？

または、オブジェクトが持つ機能を記述するためのインターフェースを提供するために、基本クラスがブール変数を提供する必要がありますか？

例：

if (account is IResetsPassword)
       ((IResetsPassword)account).ResetPassword();
else
       Print("Not allowed to reset password with this account type!");

対

if (account.CanResetPassword)
       ((IResetsPassword)account).ResetPassword();
else
       Print("Not allowed to reset password with this account type!");

機能の識別にインターフェイス実装を使用することには落とし穴がありますか？

この例は単なる例でした。もっと一般的なアプリケーションについて考えています。

可能であればダウンキャストを避けるのが最善であるという注意事項があるため、2つの理由から最初の形式が望ましいです。

1. 型システムを機能させます。最初の例では、is火災が発生するとダウンキャストが確実に機能します。2番目の形式では、実装するオブジェクトのみIResetsPasswordがそのプロパティに対してtrueを返すことを手動で確認する必要があります
2. 壊れやすい基本クラス。追加するすべてのインターフェイスの基本クラス/インターフェイスにプロパティを追加する必要があります。これは面倒でエラーが発生しやすくなります。

これは、これらの問題を多少改善できないと言っているわけではありません。たとえば、基本クラスに、インクルードをチェックできる一連の公開されたインターフェイスを持たせることができます。しかし、実際には、既存の型システムの冗長な部分を手動で実装しているだけです。

ところで私の自然な好みは継承よりも合成ですが、それは主に状態に関してです。通常、インターフェイスの継承はそれほど悪くはありません。また、貧乏人の型階層を実装していることに気付いた場合は、コンパイラが役立つので、すでに存在する階層を使用する方が良いでしょう。

オブジェクトの機能は、実装するインターフェースによってのみ識別されるべきですか？

オブジェクトの機能をまったく特定しないでください。

オブジェクトを使用するクライアントは、それがどのように機能するかについて何も知る必要はありません。クライアントは、オブジェクトに実行するよう指示できることだけを知っている必要があります。オブジェクトに通知されると、クライアントの問題ではありません。

というよりも

if (account is IResetsPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

または

if (account.CanResetPassword)
    ((IResetsPassword)account).ResetPassword();
else
    Print("Not allowed to reset password with this account type!");

考える

account.ResetPassword();

または

account.ResetPassword(authority);

accountこれが機能するかどうかはすでにわかっているからです。なぜ聞くのですか？あなたが望むことを伝えて、それが何をしようとしてもやらせてください。

これが他の問題であるためにクライアントがそれが機能するかどうか気にしないような方法で行われたと想像してください。クライアントの仕事は、試みをすることだけでした。それは今や完了しており、他に対処すべきことがあります。このスタイルには多くの名前がありますが、私が一番好きな名前は教えてください、尋ねないでください。

クライアントを書くとき、あなたはすべてを追跡しなければならないと思うので、あなたが知る必要があると思うすべてをあなたに引き寄せることは非常に魅力的です。それを行うと、オブジェクトを裏返しにします。あなたの無知を大切に。詳細を押しのけ、オブジェクトにそれらを処理させます。知れば知るほど良くなります。

バックグラウンド

継承は、オブジェクト指向プログラミングの目的を果たす強力なツールです。ただし、すべての問題をエレガントに解決できるわけではありません。他のソリューションの方が優れている場合もあります。

初期のコンピューターサイエンスのクラス（CS学位を持っていると仮定）を振り返ると、顧客がソフトウェアに何をして欲しいかを述べた段落を与えた教授を覚えているかもしれません。あなたの仕事は、段落を読み、アクターとアクションを特定し、クラスとメソッドが何であるかの大まかな概要を理解することです。そこには、重要であるように見えるが重要ではないいくつかのバムリードがあります。要件を誤って解釈する可能性も非常にあります。

これは、経験豊富な私たちでさえ間違っている重要なスキルです。要件を適切に特定し、それらを機械語に翻訳します。

あなたの質問

あなたが書いたことに基づいて、クラスが実行できるオプションのアクションの一般的なケースを誤解していると思います。はい、あなたのコードは単なる例であり、一般的なケースに興味があることを知っています。ただし、オブジェクトの特定のサブタイプはアクションを実行できますが、他のサブタイプはできないという状況を処理する方法を知りたいようです。

などのオブジェクトにaccountアカウントタイプがあるからといって、それがオブジェクト指向言語のタイプに変換されることを意味するわけではありません。人間の言語の「タイプ」は、必ずしも「クラス」を意味するとは限りません。アカウントのコンテキストでは、「タイプ」は「許可セット」とより密接に相関する場合があります。ユーザーアカウントを使用してアクションを実行したいが、そのアクションはそのアカウントで実行できる場合とできない場合があります。継承を使用するのではなく、デリゲートまたはセキュリティトークンを使用します。

私のソリューション

実行できるオプションのアクションをいくつか持つアカウントクラスを考えます。継承を介して「アクションXを実行できます」を定義する代わりに、アカウントがデリゲートオブジェクト（パスワードリセッタ、フォーム送信者など）またはアクセストークンを返さないようにしましょう。

account.getPasswordResetter().doAction();
account.getFormSubmitter().doAction(view.getContents());

AccountManager.resetPassword(account, account.getAccessToken());

最後のオプションの利点は、アカウントの資格情報を使用して他の人のパスワードをリセットしたい場合はどうなりますか？

AccountManager.resetPassword(otherAccount, adminAccount.getAccessToken());

システムがより柔軟になるだけでなく、型キャストを削除しただけでなく、デザインがより表現力豊かになりました。これを読んで、それが何をしていてどのように使用できるかを簡単に理解できます。

TL; DR：これはXY問題のようになります。一般に、次善の2つのオプションに直面した場合、一歩下がって「ここで本当に何を達成しようとしているのかを考えてみてください。タイプキャストを完全に削除しますか？」

ビル・ヴェナーは、あなたのアプローチは絶対に素晴らしいと言います。「instanceofを使用するタイミング」というタイトルのセクションにジャンプします。その特定の動作のみを実装する特定のタイプ/インターフェースにダウンキャストしているため、それを選択するのは絶対に正しいことです。

ただし、別のアプローチを使用する場合は、ヤクを剃る方法がたくさんあります。

ポリモーフィズムアプローチがあります。すべてのアカウントにパスワードがあるため、すべてのアカウントが少なくともパスワードのリセットを試みることができると主張できます。つまり、基本アカウントクラスにはresetPassword()、すべてのアカウントが独自の方法で実装するメソッドが必要です。問題は、機能が存在しない場合にそのメソッドがどのように動作するかです。

パスワードをリセットするかどうかに関係なく、voidを返し、静かに完了します。パスワードをリセットしない場合は、メッセージを内部的に出力する責任があります。最良のアイデアではありません。

リセットが成功したかどうかを示すブール値を返すことができました。そのブール値をオンにすると、パスワードのリセットに失敗したと関連付けることができます。

パスワードリセットの試行結果を示す文字列を返す可能性があります。文字列は、リセットが失敗した理由の詳細を提供し、出力される可能性があります。

それは、より詳細を伝え、以前のすべての戻り要素を結合するResetResultオブジェクトを返すことができます。

その機能を持たないアカウントをリセットしようとすると、voidを返し、代わりに例外をスローする可能性があります（通常のフロー制御に例外処理を使用することはさまざまな理由で悪い習慣です）。

canResetPassword()概念的には、それが記述されたときにクラスに組み込まれた静的な機能であるため、マッチングメソッドを持つことは、世界で最悪のものとは思えないかもしれません。ただし、機能が動的であり、canResetPassword()変更される可能性があることを示唆しているため、メソッドアプローチが悪い考えである理由の手がかりになります。他の場所で述べたように、許可を求めるのではなく伝えてください。

継承を介した合成はオプションになる可能性があります。最終passwordResetterフィールド（または同等のゲッター）と同等のクラスを使用して、呼び出す前にnullをチェックできます。許可を求めるように少し動作しますが、ファイナリティは、推測される動的な性質を回避する場合があります。

機能を独自のクラスに外部化すると考えられます。このクラスは、パラメーターとしてアカウントを取得し、それを実行することができます（例：resetter.reset(account)よくない習慣です）

この機能を備えた言語では、ミックスインまたはトレイトを使用する場合がありますが、それらの機能の存在を確認する可能性のある場所から始めます。

この具体的な例については、「パスワードをリセットすることができます」、私は相続オーバー構図使用してお勧めします（この場合は、インタフェース/契約の継承を）。なぜなら、これを行うことにより：

class Foo : IResetsPassword {
    //...
}

クラスがパスワードをリセットできることを（コンパイル時に）すぐに指定しています。ただし、シナリオで機能の存在が条件付きであり、他のものに依存する場合、コンパイル時にそれを指定することはできません。次に、これを行うことをお勧めします：

class Foo {

    PasswordResetter passwordResetter;

}

これで、実行時に、myFoo.passwordResetter != nullこの操作を行う前に確認できます。さらに多くのものを分離したい場合（さらに多くの機能を追加する予定の場合）、次のことができます。

class Foo {
    //... foo stuff
}

class PasswordResetOperation {
    bool Execute(Foo foo) { ... }
}

class SendMailOperation {
    bool Execute(Foo foo) { ... }
}

//...and you follow this pattern for each new capability...

更新

OPから他のいくつかの回答とコメントを読んだ後、私は質問が構成的なソリューションに関するものではないことを理解しました。だから私は、以下のようなシナリオで、一般的にオブジェクトの機能をよりよく識別する方法についての質問だと思います：

class BaseAccount {
    //...
}
class GuestAccount : BaseAccount {
    //...
}
class UserAccount : BaseAccount, IMyPasswordReset, IEditPosts {
    //...
}
class AdminAccount : BaseAccount, IPasswordReset, IEditPosts, ISendMail {
    //...
}

//Capabilities

interface IMyPasswordReset {
    bool ResetPassword();
}

interface IPasswordReset {
    bool ResetPassword(UserAccount userAcc);
}

interface IEditPosts {
    bool EditPost(long postId, ...);
}

interface ISendMail {
    bool SendMail(string from, string to, ...);
}

ここで、言及したすべてのオプションを分析してみます。

OPの2番目の例：

if (account.CanResetPassword)
       ((IResetsPassword)account).ResetPassword();
else
       Print("Not allowed to reset password with this account type!");

このコードがベースアカウントクラス（例：BaseAccount私の例では）を受け取っているとしましょう。これは、基底クラスにブール値を挿入し、そこに存在する意味がまったくないコードで汚染しているため、悪いです。

OPの最初の例：

if (account is IResetsPassword)
       ((IResetsPassword)account).ResetPassword();
else
       Print("Not allowed to reset password with this account type!");

質問に答えるには、これは前のオプションよりも適切ですが、実装によってはLの強固な原則を破り、おそらくこのようなチェックがコード全体に広がり、さらなるメンテナンスが難しくなります。

CandiedOrangeのanser：

account.ResetPassword(authority);

このResetPasswordメソッドがBaseAccountクラスに挿入されると、OPの2番目の例のように、不適切なコードで基本クラスが汚染されます

雪だるまの答え：

AccountManager.resetPassword(otherAccount, adminAccount.getAccessToken());

これは良い解決策ですが、機能は動的であると見なされます（時間とともに変化する可能性があります）。ただし、OPからいくつかのコメントを読んだ後、ここでの話はポリモーフィズムと静的に定義されたクラスに関するものだと思います（ただし、アカウントの例は動的なシナリオを直感的に指し示しています）。EG：このAccountManager例では、権限のチェックはDBへのクエリです。OPの質問では、チェックはオブジェクトのキャストの試みです。

私からの別の提案：

高レベルの分岐にはテンプレートメソッドパターンを使用します。上記のクラス階層はそのまま保持されます。基本クラスを汚染するキャストや不適切なプロパティ/メソッドを避けるために、オブジェクトに対してより適切なハンドラーのみを作成します。

//Template method
class BaseAccountOperation {

    BaseAccount account;

    void Execute() {

        //... some processing

        TryResetPassword();

        //... some processing

        TrySendMail();

        //... some processing
    }

    void TryResetPassword() {
        Print("Not allowed to reset password with this account type!");
    }

    void TrySendMail() {
        Print("Not allowed to reset password with this account type!");
    }
}

class UserAccountOperation : BaseAccountOperation {

    UserAccount userAccount;

    void TryResetPassword() {
        account.ResetPassword(...);
    }

}

class AdminAccountOperation : BaseAccountOperation {

    AdminAccount adminAccount;

    override void TryResetPassword() {
        account.ResetPassword(...);
    }

    void TrySendMail() {
        account.SendMail(...);
    }
}

辞書/ハッシュテーブルを使用して操作を適切なアカウントクラスにバインドしたり、拡張メソッドを使用して実行時操作を実行したり、dynamicキーワードを使用したり、最後のオプションとしてアカウントオブジェクトを操作に渡すために1つのキャストのみを使用したりできます（この場合、キャストの数は1つだけです（操作の開始時）。

あなたが提示したオプションはどちらも良いオブジェクト指向ではありません。オブジェクトの型に関するif文を書いている場合、OOを間違っている可能性が高いです（例外があり、これは1つではありません）。

interface IAccount {
  bool CanResetPassword();

  void ResetPassword();

  // Other Account operations as needed
}

public class Resetable : IAccount {
  public bool CanResetPassword() {
    return true;
  }

  public void ResetPassword() {
    /* RESET PASSWORD */
  }
}

public class NotResetable : IAccount {
  public bool CanResetPassword() {
    return false;
  }

  public void ResetPassword() {
    Print("Not allowed to reset password with this account type!");}
  }

元のコードが行っていたことと一致するように、この例を修正しました。いくつかのコメントに基づいて、これがここでの「正しい」特定のコードであるかどうかに人々が夢中になっているようです。これはこの例のポイントではありません。ポリモーフィックのオーバーロード全体は、オブジェクトのタイプに基づいてロジックのさまざまな実装を条件付きで実行することです。両方の例であなたがしていることは、あなたの言語が機能としてあなたに与えるものを手で妨害することです。簡単に言えば、サブタイプを削除し、アカウントタイプのブールプロパティとしてリセットする機能を追加できます（サブタイプの他の機能は無視されます）。

設計のより広い視野がなければ、これが特定のシステムに適したソリューションであるかどうかを判断することは不可能です。それは簡単で、あなたがやっていることに対して機能するなら、誰かがResetPassword（）を呼び出す前にCanResetPassword（）をチェックし損ねない限り、あなたはおそらくそれについて再び考える必要はないでしょう。また、ブール値を返すか、サイレントに失敗することもあります（推奨されません）。それは本当に設計の詳細に依存します。

回答

あなたの質問に対する私の少し意見を述べた答えは：

オブジェクトの機能は、インターフェースを実装することではなく、それ自体で識別する必要があります。ただし、静的に強く型付けされた言語は、この可能性を制限します（設計上）。

補遺：

オブジェクトタイプの分岐は悪です。

とりとめのない

c#タグを追加しなかったが、一般的なobject-orientedコンテキストで尋ねていることがわかります。

あなたが説明しているのは、静的/強い型付けされた言語の技術性であり、「OO」全体に特化したものではありません。あなたの問題は、とりわけ、コンパイル時に十分に狭い型を持たずにそれらの言語でメソッドを呼び出すことができないという事実に起因します（変数定義、メソッドパラメーター/戻り値定義、または明示的なキャストのいずれかを使用）。過去にこれらの種類の言語で両方のバリアントを作成しましたが、最近はどちらもいように見えます。

動的に型指定されたオブジェクト指向言語では、「ダックタイピング」と呼ばれる概念のため、この問題は発生しません。要するに、これは基本的にオブジェクトの型をどこでも宣言しないことを意味します（作成時を除く）。オブジェクトにメッセージを送信すると、オブジェクトはそれらのメッセージを処理します。オブジェクトが実際にその名前のメソッドを持っているかどうかは気にしません。一部の言語には、method_missingこれをさらに柔軟にする汎用の包括的メソッドさえあります。

したがって、そのような言語（Rubyなど）では、コードは次のようになります。

account.reset_password

期間。

accountどちらか、パスワードをリセット「拒否」例外をスロー、または「『reset_password』を処理する方法がわからない」例外がスローされます。

何らかの理由で明示的に分岐する必要がある場合、クラスではなく機能で分岐します。

account.reset_password  if account.can? :reset_password

（can?オブジェクトを呼び出さずに、オブジェクトが何らかのメソッドを実行できるかどうかをチェックするメソッドだけがあります。）

私の個人的な好みは現在、動的に型付けされた言語を使用していますが、これは単なる個人的な好みです。静的に型付けされた言語にも同様のことがありますので、静的に型付けされた言語に対するバッシングとしてこのとりとめを受け取らないでください...

あなたのオプションは異なる動機付けの力から派生しているようです。1つ目は、オブジェクトモデリングの質が低いために採用されたハックのようです。ポリモーフィズムを壊すため、抽象化が間違っていることが実証されました。おそらくそれは、オープンな閉原理を破り、より緊密な結合をもたらします。

2番目のオプションはOOPの観点からは問題ないかもしれませんが、型キャストは私を混乱させます。アカウントでパスワードをリセットできる場合、なぜ型キャストが必要なのですか？したがって、CanResetPassword条項がアカウントの抽象化の一部である基本的なビジネス要件を表していると仮定すると、2番目のオプションは問題ありません。