いつ継承を使用するか、「ブール値フィールドのみ」を使用するか？

Railsアプリケーションでは、通知を追加しています。これらの一部は次のとおりblockingです。リソースに関する情報が欠落しているため、追加されたリソースの進行を停止します。

他の通知は単純な通知であり、情報のみを提供します。

今日、私たちのチームの別のプログラマーと話し合いました。次のような継承構造を作成しました。

しかし、彼は、blocking各通知にブール値を返すメソッドとして追加し、通知親クラス内でブロックしているサブクラスのリストを指定したいだけです。

これらのアプローチの違いはそれほど大きくありません。私のアプローチでは、このリストを指定する必要はなく、ルートクラスをよりクリーンに保ちます。一方、Notification::Blocking現在発生している特別なロジックもそれほど大きくありません。

この問題には、どのような抽象化がより適していますか？

基本クラスが派生クラスについて知ることを避けたい。新しい派生クラスを作成するたびにリストに追加することを覚えておく必要があるため、密結合を導入し、メンテナンスの頭痛の種です。

また、このクラスを複数のプロジェクトで使用する場合、Notificationクラスを再利用可能なパッケージ/アセンブリに配置することもできなくなります。

単一の基本クラスを実際に使用する場合、これを解決する別の方法は、基本Notificationクラスに仮想プロパティまたはメソッドIsBlockingを追加することです。派生クラスはそれをオーバーライドして、trueまたはfalseを返します。基本クラスが派生クラスを知らなくても、単一クラスのソリューションがあります。

そして、通知親クラス内でブロックしているサブクラスのリストを指定します。

それは非常に奇妙に見え、特定のコードの匂いです。

クラス間の動作に違いがあり、これらすべての通知を同じ方法で処理する場合（つまり、ポリモーフィズムを使用する場合）にサブクラスを提供します。

既存の答えとは逆に、使用するモードを動的に変更する必要がある場合は、ブール型プロパティが最適なオプションであることをお勧めします（たとえば、ブロックするタイプのリストを提供する構成ファイルを介してどちらでもない）。

そうは言っても、この状況でもより良い設計は、Decoratorオブジェクトを使用することです。

私が最初に考えたのは「両方」を使用することですが、ブロッキング通知に関して他にどれだけ特別なものがあるかによると思います。

class Notification
 virtual Boolean Blocking{get return false;}

class BlockingNotification inherits Notification
 virtual overrides Boolean Blocking{get return true;}

そのように、n.Blockingまたはn is BlockingNotification（すべて擬似コードで）を使用できますが、クラスにコンテキスト依存のBlocking値を実装させる場合、その値を毎回確認する必要があるため、BlockingNotificationクラスは次のようになります。あまり役に立たない。

いずれにせよ、基本クラスの実装にBlocking派生クラスについて知ってもらいたくないという他の答えに同意します。

2つの基本クラスとそれぞれの複数のインスタンスを作成する代わりに、boolを使用して1つの通知クラスを作成し、通知がブロックされているかどうか、および通知をユーザーに伝えるために必要なその他の情報を示します。

これにより、通知の処理と表示に1セットのコードを使用でき、コードの複雑さが軽減されます。