Mixinsは通常、クラスに新しい動作を導入することを考えると 、これは通常、クラスに複数の動作があることを意味します。
クラスに単一の責任がある場合、これは変更の理由が1つしかないクラスとして定義されます。
だから、私はこれを2つの異なる視点から見ることができます
クラスには変更の理由が1つだけあります。混合されたモジュールにも、変更の理由が1つだけあります。クラスが変更された場合、クラスのみを再テストする必要があります。モジュールを変更した場合は、モジュールのみを再テストする必要があります。したがって、SRPはそのままです。
クラスには、変更の2つの理由があります。クラスが変更された場合、クラスとモジュールの両方を再テストする必要があります。モジュールが変更された場合は、クラスとモジュールの両方を再テストする必要があります。ヘンジ、SRPに違反しています。
ミックスインの使用は単一責任の原則に違反し、最終的にはシステムの保守が困難になりますか？
ミックスインが一般にクラスに新しい動作を導入することを考えると、これは通常、クラスが複数の動作を持つことを意味します。
それが本当なら、単一の (実装) 継承についても同様に当てはまります。23 の深さの継承階層を好む人はもういませんが、それでもその場所はあります。
継承が SRP を壊さない理由は、それが話しているクラスが文字通りのコード ファイルの意味でのクラスであり、より抽象的なものではないからです。基本クラスのコード ファイルを変更する場合、通常、そのファイルを変更する必要はありません。
したがって、それを変更する単一の理由が維持されます。
mixin次第だと思います。追加の責任を与えることになるかもしれませんが、Ruby の Comparable のように、SRP に違反していないと言えるかなり低レベルの機能を提供するものもあります。
関連のないクラス間で動作を共有する必要がある場合 (場合によっては共有する必要がある場合) には、基本的に 3 つのオプションがあります。
テストに関しては、「優れた」ミックスインは、優れた通常のメソッドと同様に、それとそれを使用するクラスが独立して使用できるように十分に疎結合する必要があると主張します。
私はそれに同意します。ただし、SRP は違反する場合があります (または違反する必要があります) 。