私はButtonModifierから派生したVolumeButtonを持っています。ビジネスロジック（音量のアップ/ダウン、ミュートなど）をVolumeButtonに入れた場合、ロジックを有効/無効にしてButtonModifierクラスをベースにします。 Like基本クラスには1つの責任があり、派生クラスには別の責任があります。これはSRPに準拠していますか？
一方、ビジネスロジックの変更のみがVolumeButtonに影響し、インフラストラクチャの変更はButtonModifierに影響します。 SRPに準拠しています。一方、VolumeButtonは、基本クラスからの有効/無効ロジックを継承しました。それには2つの責任がありますか？
これらの2つのクラスはSRPに準拠していますか？
VolumeButtonとButtonModifierの両方には、別々に変更する理由が1つしかありません。したがって彼らは文字通りSRPに準拠しています。しかし、直感的に私はVolumeButtonがButtonModifieからの責任を継承していると考えています。これはSRPに違反してしまいます。
コードの依存関係の観点から、派生クラスから基本クラスに1つの責任を移すことによって、依存関係を切り離すことはありませんでした。 Bobさんの「C＃における敏捷な原則、パターンと実践」Chapter 8によれば、Bobのおじさんは責任を分けるために余分な抽象概念を導入しました。あなたの質問に役立つヒントは、「依存関係を切り離すために余分な抽象概念を導入しましたか？
私は、派生クラスは、例えば、その基底クラスからのすべてのパブリック/保護されたメンバーを取得するので、彼らは、SRPに適合しているとは思わない：
public class Flyable
{
public void fly(){...}
}
public class Bird : Flyable
{
public void walk(){...}
}
鳥が飛ぶと歩くことができます。 例があなたの場合には正確ではないかもしれません。しかし、私が言いたいのは、2つの責任が基底と1つの派生クラスで分離されている場合、派生クラスは2つの責任を負うということです。