単一責任原則（SRP）-各クラスに変更する理由を1つだけ与えます。および「変更の理由」==「責任」。例：Invoiceクラスは、それ自体を印刷する責任がありません。
懸念の分離（1974年以降）。懸念==システムの機能。懸念事項のそれぞれに対処する：懸念事項ごとに、他の懸念事項は無関係です。動作の実装を非表示にします。
ここ から。
リンクされた記事から：
懸念の分離（SoC）–コンピュータープログラムを、機能ができるだけ重複しない個別の機能に分割するプロセスです。懸念事項とは、プログラムで関心のある部分または焦点のある部分です。通常、懸念事項は機能または動作と同義です。 http://en.wikipedia.org/wiki/Separation_of_concerns
単一の責任の原則（SRP）–すべてのオブジェクトは単一の責任を持つ必要があり、すべてのサービスはその責任に厳密に一致する必要があります。あるレベルでは、凝集度はSRPの同義語と見なされます。 http://en.wikipedia.org/wiki/Single_responsibility_principle
単一の責任とは、オブジェクトが単一の作業単位に対して責任を負うことを示します。
関心の分離は、機能ができるだけ重複しないモジュールにアプリケーションを分割する必要があることを示しています。
同様の最終結果...わずかに異なるアプリケーション。
私の意見では、単一責任原則は懸念の分離を達成するためのツール/イディオムの1つです。
単一責任の原則と懸念の分離は、まったく同じものです。
確かに、この2つの違いを理解しようとする学術的議論に行き詰まる可能性がありますが、なぜでしょうか。すべての意図と目的のために、彼らは同じことを説明しています。最大の問題は、人々が「懸念」と「責任」が何であるかを正確に知りたいことに夢中になり、おそらくSRPとSoCの背後にある重要なアイデアを見逃していることです。
そのアイデアは、コードベースを疎結合の分離された部分に分割することです。これにより、複数の開発者が互いに影響を与えずに異なるパーツで作業できるようになります。また、1人の開発者が別のパーツを壊すことなく1つの分離されたパーツを変更することもできます。
これはモジュールレベルで適用されます。たとえば、MVCはSRPとSoCを促進するアーキテクチャパターンです。コードベースは、分離されたモデル、ビュー、コントローラーに分割されます。これにより、ビューの変更をモデルとは独立して行うことができます。 2つ2つは恐ろしく絡み合っていません。
下位レベルでは、これはクラスにも適用する必要があります。 1つのクラスに数十のメソッドを配置する代わりに、コードをいくつかに分割します。同じ理由で。
また、メソッドレベルでも、大きなメソッドを小さなメソッドに分割します。
原則として。 SRPは原則ではなく、原則です。したがって、SRPを極端に忠実にフォローする必要はありません（読む：できない/すべきではありません）。たとえば、行き過ぎて、各クラスに7行のメソッドが1つしかないという意味ではありません。これは、コードを分離された部分に分割する一般的な原則を意味します。ポイントは、それがより良いコードベースとより安定したソフトウェアにつながるということです。
懸念の分離（SoC）機能の重複をできるだけ少なくして、アプリケーションを個別の機能に分割します。 （マイクロソフト）。
"懸念" = "個別の機能" = "個別のセクション"
「懸念」は高レベルと低レベルの両方で機能します
単一責任の原則は、すべてのモジュールまたはクラスが、ソフトウェアによって提供される機能の単一の部分に対して責任を負うべきであり、その責任はクラスによって完全にカプセル化される必要があることを述べています。そのすべてのサービスは、その責任と厳密に一致している必要があります。 （ウィキペディアの定義）
「責任」=「変更する理由」何を変更しますか？ 「ソフトウェアによって提供される機能の単一部分」= Basic Unit
結論
単一責任原則は基本単位で機能します->低レベルで機能します
懸念の分離は高レベルと低レベルの両方で機能します
SRPとSoCは連携して問題を分離します。彼らです
低レベルでもまったく同じ
懸念の分離はプロセスです。単一責任原則は、設計/アーキテクチャの哲学です。それらは完全にばらばらではありませんが、目的は異なります。
以前の回答では 単一の責任の原則 を作成したRobert Martinを引用していないため、ここではより信頼できる回答が必要だと思います。
MartinのSRPへのインスピレーションは、David Parnas、Edsger Dijkstra（用語Separation of Concernsを作成した）とLarry Constantine（用語CouplingandCohesion）マーティンはアイデアをSRPに統合しました。
単一責任原則の別の表現は次のとおりです。
同じ理由で変化するものを集めます。さまざまな理由で変化するものを分離します。
これについて考えると、これはまとまりと結合を定義するためのもう1つの方法にすぎないことがわかります。私たちは同じ理由で変化するものの間の結束を高め、異なる理由で変化するものの間の結合を減らしたいと考えています。
ただし、この原則について考えるとき、変更の理由はpeopleであることに注意してください。変更を要求するのはpeopleです。そして、さまざまな理由で多くの異なる人々が気にかけているコードを一緒に混ぜることによって、それらの人々または自分自身を混乱させたくないでしょう。
元の質問に対して、SRPとSoCの小さな違いは、マーティンが懸念事項をを参照するように改良したことです人。
SRPとSOCは異なるレベルの抽象化で機能します。どちらの場合も、カップリングを減らし、凝集力を強化することが目的です。 SRPはオブジェクトレベルでより多く機能しますが、SOCは機能レベルの実装で機能する場合もあります。関数は、1つのオブジェクトだけでなく、複数のオブジェクトによっても実装できます。したがって、両方の原理の結合と結束は異なる場合があります。
懸念の分離（SoC）と単一責任原則（SRP）の比較を試みました。
違い
SRPはクラスレベルですが、SoCは各コンピュータープログラム、抽象化…、または場合によってはアーキテクチャレベルにあります。
SRPは、ドメインを1つの責任（変更する理由の1つ）だけを持つまとまりのあるクラスに分割する（何ではないか）の品質に関するものです。一方、SoCは、コンテキストを個別のセクションに分割するための設計原則です。たとえば、クラス、関数、モジュール、パッケージなどの多くのツールがあるため、各セクションは個別の問題（方法ではない）に対処します。 ..）この目標をさまざまなレベルに到達させる。
SRPの概念は凝集度（高凝集度）に基づいていますが、SoCは抽象化の各レベルで分子性、分割統治（D＆C）などに近いものです。
SoCは抽象化などの複雑さに対処するための優れた設計原則ですが、単一の責任のあるクラスに到達するには、優れたソリューションとしてSoC原則を使用できます。同様に、クラスに複数の責任があることを知る方法は、そのクラスから別の責任（懸念）を抽出できる場合です。
類似点
- これらの各原則を適用した後、コンテキストはより再利用可能で、保守可能で、堅牢で、読みやすくなります。
同様ですが、SoCは懸念事項に関連しています。複雑な問題をいくつかの懸念事項に分解するために、SRPは1つの責任を持つだけです。
回答：
関心の分離（SoC）はより用途の広い用語です-システムレベルまたはクラス（またはメソッド）のようなより低いレベルで適用できますクラス内）
単一責任原則（SRP）は、下位レベルでのSoCの議論に使用されます。クラスで
それについて考える方法：
低レベルでは、SoCとSRPは同義です。つまり、SRPは冗長な用語であると言えるでしょう。または、SoCはシステムレベルの説明にのみ使用するべきです。
（1）の場合、SoCという用語はややあいまいです。ディスカッションが高レベルSoCに関するものか、低レベルSoCに関するものかを理解するためのコンテキストが必要です。
SRPが下位レベルのみの用語であることを思い出すために、これについて考えてください。日常の言語では、「責任」は通常、特定のコードに結び付けることができる明確に定義されたものですが、「懸念」は通常、あいまいであり、 SoCがシステムレベルの議論にSRPよりも自然に適しているのはおそらくそのためです。
SoCは、ある意味では、システムレベルで適用されるため、SRPよりも強い要件/原則であり、システムレベルで真に達成されるためには、システムコンポーネント。つまり、高レベルのSoCは、低レベルでのまともなSoC/SRPを意味しますが、その逆は当てはまりません。つまり、低レベルのSoC/SRPは、次の高レベルのSoCまたは何も意味しません。包含システム。メソッドレベルで達成され、その後クラスレベルで違反されるSoC/SRPの例については、これをチェックしてください Artur Trosinのブログ投稿 。