このテキストで私は読んだ
単なる栄光の責任であるコンポーネントに注意してください。コンポーネントは、システムで目的を持つ抽象化をキャプチャすることになっています。ある瞬間に意味のあるコンポーネントとして表示されるのは、実際にはそれ自体に残された単一の責任である場合があります。その責任をコンポーネントに割り当てることができます。
これは私を混乱させます。クラスに変更する理由が1つしかない場合は、1つの責任があるように思われます。しかし、今はこれを狭すぎているようです。責任ベースのモデリングのコンテキストで、責任と変更する理由をどういうわけか説明できますか？クラスに3つ以上の責任があり、それでも変更する理由が1つある（またはその逆）ことができますか？
クラス-責任-コラボレーションモデリング（または設計）について読む
http://www.agilemodeling.com/artifacts/crcModel.htm
http://alistair.cockburn.us/Using+CRC+cards
http://users.csc.calpoly.edu/~jdalbey/SWE/CaseStudies/ATMSim/CRCmodel.html
http://c2.com/doc/oopsla89/paper.html
クラスにはいくつかの責任があります。それは常に単一の「もの」を表します。
「変更する1つの理由」のルールは、責任には適用されません。限目。
「変更する1つの理由」ルールは次のように使用する必要があります。
「1」という意味ではありません。それは「できるだけ少ない」という意味です。
これは、クラスの「インターフェース」または「基礎となる抽象化」または「概念」に適用されます。クラスはいくつかの概念をカプセル化する必要があります。そのコアコンセプトが変わると、クラスも変わります。
多くの単純なものは、いくつかの複雑なものよりも優れています。単純なものを再結合して変更する方が簡単です。
すべての複雑なものの中には、自由になろうとする多くの単純なものがあります。
「シンプル」を定義するのは難しいですが、「1つのコンセプト」は近いです。「変更する1つのこと」は、「シンプルさ」のテストにも役立ちます。
最後に、「変更する1つの理由」は、文字通り「1」を意味するものではありません。
私の理解では、「コンポーネントに対する責任を美化する」ことの危険性は、責任をシステムコンポーネントに直接変換しないように注意する必要があることを意味します。
たとえば、電子メールシステムでは、ユーザーは受信者へのメッセージを開始することを目的としてシステムにアプローチする場合があります。これを可能にするのはシステムの責任です。
ユーザーは、システムにアクセスして電子メールを読んだり返信したりすることもできます。これを可能にするのもシステムの責任です。
しかし、これは、システムに「新しい電子メールを開始する」と「電子メールに返信する」という2つのコンポーネントが必要であることを意味しますか？いいえ。一般的な「電子メールの作成」コンポーネントは、両方の要件を処理できます。
したがって、この場合、コンポーネント「電子メールの作成」は、ユーザーの目標「新着メールの開始」と「メールへの返信」を担当します。ただし、変更する必要があるのは、コアコンセプト（「電子メールの作成方法」）が変更された場合のみです。
Cockburnによる次のフレーズをもう一度よく見てください。「コンポーネントは、システムで目的を持つ抽象化をキャプチャすることになっています」。システムの目的（変更の理由）は、ユーザーの目標（責任）を達成する目的と同じではありません。
簡単に言うと、私の理解では、コンポーネントには理想的には1つのコアコンセプトがあります。それにはいくつかの責任があるかもしれません。しかし、私が見ているように、1つの責任が複数のコンポーネントに割り当てられていない可能性があります。