単一責任の原則と関心の分離の違いは何ですか？
回答:
単一責任原則（SRP）-各クラスに変更する理由を1つだけ与えます。および「変更の理由」==「責任」。例：請求書クラスには、それ自体を印刷する責任はありません。
関心の分離（1974年以降）。懸念==システムの機能。それぞれの懸念に対処する：それぞれの懸念について、他の懸念は無関係です。動作の実装を非表示にします。
ここから。
私の意見では、単一責任原則は、関心の分離を達成するためのツール/イディオムの1つです。
リンクされた記事から：
関心の分離（SoC） –コンピュータープログラムを、機能の重複をできるだけ少なくする別個の機能に分割するプロセスです。懸念事項は、プログラムの関心や焦点です。通常、懸念事項は機能または動作と同義です。 http://en.wikipedia.org/wiki/Separation_of_concerns
単一責任原則（SRP） –すべてのオブジェクトには単一の責任があり、そのすべてのサービスはその責任と狭く整合している必要があります。あるレベルでは、結束はSRPの同義語と見なされます。 http://en.wikipedia.org/wiki/Single_responsibility_principle
単一責任は、オブジェクトが単一の作業単位に責任があることを示します。
関心の分離では、アプリケーションを、機能の重複ができるだけ少ないモジュールに分割する必要があると述べています。
同様の最終結果...わずかに異なるアプリケーション。
単一責任の原則と関心の分離は、実際には同じものです。
確かに、2つの間のある種の違いを引き出しようとする学術的な議論に行き詰まる可能性がありますが、なぜですか？すべての意図と目的のために、それらは同じことを説明します。最大の問題は、人々が「懸念」と「責任」が何であるかを正確に知りたいと思うことに夢中になり、SRPとSoCの背後にある重要なアイデアを見逃してしまうことです。
そのアイデアは、コードベースを疎結合の分離された部分に分割することです。これにより、複数の開発者が互いに影響を与えることなく異なるパーツで作業できるようになり、1人の開発者が別のパーツを壊すことなく1つの分離されたパーツを変更できるようになります。
これはモジュールレベルで適用されます。たとえば、MVCはSRPとSoCを促進するアーキテクチャパターンです。コードベースは、分離されたモデル、ビュー、およびコントローラーに分割されています。このようにして、ビューの変更をモデルとは独立して行うことができます。2つ2つは恐ろしく絡み合っていません。
下位レベルでは、これはクラスにも適用する必要があります。1つのクラスに数十のメソッドを配置する代わりに、コードをいくつかに分割します。同じ理由で。
また、メソッドレベルでも、大きなメソッドを小さなメソッドに分割します。
原則として。SRPは原則であり、規則ではないため、極端に宗教的に従う必要はありません（読む：できない/従うべきではありません）。たとえば、行き過ぎて、各クラスに7行のメソッドが1つしかないという意味ではありません。これは、コードを分離された部分に分割するという一般的な原則を意味します。重要なのは、より良いコードベースとより安定したソフトウェアにつながるということです。
関心の分離（SoC）。アプリケーションを個別の機能に分割し、機能の重複をできるだけ少なくします。（マイクロソフト）。
「懸念」=「個別の機能」=「個別のセクション」
「懸念」は高レベルと低レベルの両方で機能します
単一責任の原則 は、すべてのモジュールまたはクラスがソフトウェアによって提供される機能の単一の部分に対して責任を持つべきであり、その責任はクラスによって完全にカプセル化されるべきであると述べています。そのすべてのサービスは、その責任と密接に連携する必要があります。（ウィキペディアの定義）
「責任」＝「変える理由」は 何を変えるのか？「ソフトウェアが提供する機能の一部」=基本単位
結論
単一責任原則は基本ユニットで機能します->低レベルで機能します
関心の分離は、高レベルと低レベルの両方で機能します
SRPとSoCは、関心の分離のために連携して機能します。それらは
低レベルでまったく同じです
これまでの回答はいずれも、単一責任原則を作成したロバート・マーチンを引用していないため、ここではより信頼できる回答が必要だと思います。
SRPのためのマーティンのインスピレーションは、デビッド・パルナス、（用語の造語Edsgerダイクストラから引き出された関心事の分離を）および（用語造語ラリー・コンスタンティンカップリングと結束を）。マーティンは彼らのアイデアをSRPに統合しました。
単一責任原則の別の表現は次のとおりです。
同じ理由で変化するものを集めてください。さまざまな理由で変化するものを分離します。
これについて考えると、これが凝集度と結合度を定義するもう1つの方法であることがわかります。同じ理由で変化するものの間の結束を高め、異なる理由で変化するものの間の結合を減らしたいと考えています。
ただし、この原則について考えるとき、変更の理由は人であることに注意してください。変化を求めるのは人です。そして、さまざまな理由で多くのさまざまな人々が気にかけているコードを混ぜ合わせて、それらの人々や自分自身を混乱させたくはありません。
元の質問に対して、SRPとSoCの小さな違いは、マーティンが懸念という用語を洗練して人々を指すようにしたことです。
関心の分離（SoC）と単一責任原則（SRP）を比較してみました。
違い
SRPはクラスレベルですが、SoCは各コンピュータプログラム、抽象化、または場合によってはアーキテクチャレベルにあります。
SRPは、ドメインを1つの責任（変更する1つの理由）を持つまとまりのあるクラスに分割する品質（どのようにではないか）に関するものです。一方、SoCは、コンテキストを個別のセクションに分割するための設計原則であり、多くのツール（クラス、関数、モジュール、パッケージなど）があるため、各セクションが個別の懸念事項（方法ではない）に対処します。 ..）この目標をさまざまなレベルで達成する。
SRPの概念は凝集度（高凝集度）に基づいていますが、SoCは抽象化の各レベルで分子度、分割統治法（D＆C）に近いです。
SoCは、抽象化などの複雑さに対処するための優れた設計原則ですが、単一責任クラスに到達するには、SoCの原則を優れたソリューションとして使用できます。として、クラスに複数の責任があることを知る方法は、そのクラスから別の責任（懸念）を抽出できるかどうかです。
類似点
回答：
関心の分離（SoC）は、より用途の広い用語です。システムレベル、またはクラス（またはクラス内のメソッド）などの下位レベルで適用できます。
単一責任原則（SRP）は、クラスなどの下位レベルでSoCについて説明するために使用されます。
それについて考える方法：
低レベルでは、SoCとSRPは同義語です。つまり、SRPは冗長な用語である、またはSoCはシステムレベルを議論するためにのみ使用されるべきであると言えます。
（1）を考えると、SoCという用語はやや曖昧です。議論が高レベルのSoCに関するものなのか低レベルのSoCに関するものなのかを知るためのコンテキストが必要です
SRPは低レベルのみの用語であることを覚えておいてください。日常の言葉では、「責任」は通常、特定のコードに関連付けることができる明確に定義されたものですが、「懸念」は通常、漠然としたものであり、関連するものがたくさん含まれているため、SoCはSRPよりもシステムレベルの議論に自然に適合します。
SoCは、システムレベルで適用されるため、ある意味でSRPよりも強力な要件/原則であり、システムレベルで真に達成するには、システムコンポーネントの開発にも使用する必要があります。つまり、高レベルのSoCは、低レベルで適切なSoC / SRPを意味しますが、その逆は当てはまりません。つまり、低レベルのSoC / SRPは、次の高レベルのSoCまたは何かを意味しません。包括的システム。メソッドレベルで達成された後、クラスレベルで違反したSoC / SRPの例については、このArturTrosinのブログ投稿を確認してください。
関心事の分離
関心の分離（SOC）の原則では、コードアーティファクトにより、特定の側面に注意を向けることができるようにする必要があります。コードアーティファクトは、特定の関数からクラス、パッケージ全体、さらにはアプリケーション全体まで、何でもかまいません。SOCの原則は、アプリケーションのすべてのアーキテクチャレベルに適用できます。SOCが適用されるアーキテクチャの例は、階層化アーキテクチャです。
単一責任の原則
単一責任原則（SRP）は、「モジュールには変更する理由が1つだけあるべきである」と述べています（Clean Architecture、Martin、p.62）。SRPはモジュールレベルに適用され、SRPを適用するときは、変更する理由に焦点を当てる必要があります。
結論
SOCの原則では、コードアーティファクトにより、特定の側面に注意を向けることができるようにする必要があります。SRPは、モジュールレベルでは、変更の理由に注意を向けるべきであると述べて、これを具体的にしています。したがって、SRPはSOCです。
PS完全を期すために：共通の閉鎖原則
Common Closure Principle（CCP）は、さらに高いレベルであるコンポーネントレベルでのSRPの言い換えです。CCPは、同じ理由で同時に変更されるクラスは、同じコンポーネントに収集する必要があると述べています（Clean Architecture、p.105）。CCPはSOCのもう1つの例です。