派生クラスのメソッドを隠したいが、Liskov Substitution Principle に違反したくない場合があるため、そこに残して代わりにNotSupportedException
、おそらくこのメソッドがスローするコメントを付けて をスローします。
人々が派生クラスを渡す前にすべてのメソッドのすべてのコメントを読もうとしない場合、問題をコンパイル時の問題から実行時の問題に移すという意味で、そのような慣行は悪くはないにしても同じくらい悪いのではないでしょうか?
派生クラスのメソッドを隠したいが、Liskov Substitution Principle に違反したくない場合があるため、そこに残して代わりにNotSupportedException
、おそらくこのメソッドがスローするコメントを付けて をスローします。
人々が派生クラスを渡す前にすべてのメソッドのすべてのコメントを読もうとしない場合、問題をコンパイル時の問題から実行時の問題に移すという意味で、そのような慣行は悪くはないにしても同じくらい悪いのではないでしょうか?
サブクラスがそのスーパークラスのメソッドをサポートしていない場合、原則として、そのクラスを拡張するべきではないことに同意します。あなたが言及したような可能性のある例外を処理するためにランタイムチェックを要求することを超えて(パフォーマンスの最適化が必要な場合に問題になる可能性があります)、しかし、このアプローチのより大きな問題は、サブクラスからすべてのクラスに責任を移すことだと思いますこれを使用する必要があるため、ソフトウェアのカプセル化が難しくなり、その結果、保守や推論が難しくなります (ソフトウェアが大きくなるほど、問題が大きくなります)。
そうは言っても、この質問は本質的に主観的なものです。このアプローチがうまくいく場合は、必ず実行してください。個人的には、複雑な API よりも単純な API を好みますが、それが私です。