大規模なプロジェクトや API/フレームワークの設計の経験がある方に質問です。
私は将来、他の多くのプロジェクトで使用されるフレームワークに取り組んでいるので、それを素晴らしく拡張可能にしたいと考えていますが、同時にシンプルで理解しやすいものにする必要があります。
多くの人が、.NET フレームワークに含まれるシール クラスとプライベート メンバーが多すぎると不満を漏らしていることを知っています。この批判を避けて、すべての保護された仮想メンバーですべてのクラスを開く必要がありますか?
できるだけ多くのメソッドとプロパティを保護された仮想にするのは良い考えですか? どのような状況で、保護された仮想を避け、メンバーを非公開にしますか?
クラスにはデータ メンバーが含まれています。機能が変更されてはならないデータ メンバーに対して基本的な内部操作を実行するメソッドは、常にプライベートにする必要があります。そのため、初期化や割り当てなど、データ メンバーで基本的な操作を行うメソッドはプライベートにする必要があります。そうしないと、「二次」派生クラスが不完全な一連の動作を有効にする危険があります。一次派生メンバーは、クラスの動作を再定義する可能性があります。
とはいえ、メソッドを「保護された仮想」として定義することには非常に注意する必要があると思います。メソッドを「保護された仮想」として定義する際には細心の注意を払います。これを行うと、機能をオーバーライドする可能性が宣言されるだけでなく、何らかの方法でオーバーライドされた機能の期待が定義されるためです。これは、オーバーライドする一連の動作が定義されていないように思えます。むしろ、オーバーライドする明確に定義された一連の動作が必要です。オーバーライド可能なビヘイビアーの非常に大きなセットが必要な場合は、非常に構造化された方法でそのようなことを可能にする Aspect Oriented Programming を検討したいと思います。
メソッドに仮想という言葉を付けると、ユーザーはそのロジックの実行方法を変更できるようになります。多くの目的で、それはまさにあなたが望むものです。あなたはすでにそれを知っていると思います。
ただし、型はこの種の拡張用に設計する必要があります。ユーザーが動作を変更できるようにすることが理にかなっている場合は、メソッドを積極的に選択する必要があります。型の完全性を台無しにする危険性があるあらゆる場所で virtual を平手打ちすると、ユーザーが型を理解するのに実際には役に立たず、セキュリティ関連の問題を含む多くのバグが発生する可能性があります。
私は保守的なアプローチを好みます。sealed特に継承を有効にしたい場合を除き、すべてのクラスを でマークし、そのような (少数の) ケースでは、必要なメソッドのみを仮想化します。
sealed将来継承を可能にするためにクラスを変更する必要がある場合は、タグを簡単に削除できます。ただし、他の型の基本クラスとして既に使用されているクラスを変更する場合は、基本クラスを変更するときにサブクラスが壊れる危険があります。
私の見解は次のとおりです。
eventsは、メソッドよりも優先されprotectedます。protected。不可能な場合は、メソッドを使用する必要があります;-)。選択は意図的な設計protected上privateの決定です。あなたのクラスは、それに伴うすべてのオーバーヘッド (設計と実装の労力) とともに、その関数を使用することを明示的にサポートしていると述べています。protected主に私が自分で行っているため、必要であることがわかっている状況でのみ使用します。(私が言ったことと同じ方向に沿った BCL 開発者からのコメントも見つかります。)
virtual/非パフォーマンスのvirtual違いは、.NET Framework を実行するのに十分強力なマシンでは関係ありません。
いいえ、「多すぎる」ことはできません。しかし、すべてを非公開にする代わりに保護するか、「封印」を絶対に避けるべきであるという考えは、ばかげています。「ヘルパー メソッド」と内部データ構造をプライベートに保ちます。