単一責任の原則と懸念の分離の違いは何ですか

19

a）SRPとSoCの違いは何ですか？おそらくSRPはクラスレベルで適用されますが、SoCはsystem、subsystem、module、class、またはfunctionレベルで適用できます。

b）a）への回答が「はい」の場合、SoCはクラスレベルでSRPの同義語に適用されますか？

ありがとうございました

design-patterns single-responsibility

— user1483278
ソース

13

単一責任の原則は、コードが1つのことだけを行うことに関するものであり、すべての機能を特定の1つのことを行うための複数のクラスに分割できます。例として、検証、特定のビジネスロジックの実行、モデルの強化、データの取得、データの更新、ナビゲーションなどの特定のクラスがあります。

懸念の分離とは、コードが他のクラス/システムと密接に結びついていないことです。コードでインターフェイスを使用すると、クラス/システムをコードに疎結合することができます。これのプラス面は、コードの単体テストも簡単になることです。これを達成するのに役立つ多くの（IoC）フレームワークがありますが、もちろん自分でそのようなことを実装することもできます。

SoCの例ですが、SRPはありません

public class Foo
{
    private readonly IValidator _validator;
    private readonly IDataRetriever _dataRetriever;

    public Foo(IValidator validator, IDataRetriever dataRetriever)
    {
        _validator = validator;
        _dataRetriever = dataRetriever;
    }

    public NavigationObject GetDataAndNavigateSomewhereIfValid()
    {
        var data = _dataRetriever.GetAllData();

        if(_validator.IsAllDataValid(data))
        {
            object b = null;
            foreach (var item in data.Items)
            {
                b = DoSomeFancyCalculations(item);
            }

            if(_validator.IsBusinessDataValid(b))
            {
                return ValidBusinessLogic();
            }
        }
        return InvalidItems();
    }

    private object DoSomeFancyCalculations(object item)
    {
        return new object();
    }
    private NavigationObject ValidBusinessLogic()
    {
        return new NavigationObject();
    }

    private NavigationObject InvalidItems()
    {
        return new NavigationObject();
    }
}

ご覧のとおり、このコードはクラスや他のシステムと密接に結びついていません。これは、一部のインターフェイスのみを使用して作業を行うためです。これはSoCの観点からは適切です。

ご覧のとおり、このクラスには3つのプライベートメソッドが含まれています。SRPの観点から、これらのメソッドはおそらく独自のクラス内に配置する必要があります。それらの2つは、ナビゲーションで何かを行います。これは、いくつかのINavigationクラスに適合します。もう1つはアイテムに対していくつかの凝った計算を行います。これはおそらくIBusinessLogicクラス内に配置できます。

このようなものがあれば、SoCとSRPの両方が適切な場所にあります。

public class Foo
{
    private readonly IValidator _validator;
    private readonly IDataRetriever _dataRetriever;
    private readonly IBusinessLogic _businessLogic;
    private readonly INavigation _navigation;

    public Foo(IValidator validator, IDataRetriever dataRetriever, IBusinessLogic businessLogic, INavigation navigation)
    {
        _validator = validator;
        _dataRetriever = dataRetriever;
        _businessLogic = businessLogic;
        _navigation = navigation;
    }

    public NavigationObject GetDataAndNavigateSomewhereIfValid()
    {
        var data = _dataRetriever.GetAllData();

        if(_validator.IsAllDataValid(data))
        {
            object b = null;
            foreach (var item in data.Items)
            {
                b = _businessLogic.DoSomeFancyCalculations(item);
            }

            if(_validator.IsBusinessDataValid(b))
            {
                return _navigation.ValidBusinessLogic();
            }
        }
        return _navigation.InvalidItems();
    }
}

もちろん、このロジックをすべてGetDataAndNavigateSomewhereIfValidメソッドに配置する必要があるかどうかについては議論できます。これは自分で決めるべきものです。私には、この方法があまりにも多くのことをしているように見えます。

— Jan_V
ソース

「JB Kingの回答の全記事を読んだ後、それも良い記事だと思います。」しかし、JBキングの答えはあなたの答えの反対を主張しています-つまり、SoCもまた単一の責任に関するものであり、SRPよりも高いレベルで適用できるということです

— -user1483278

2

クラスレベルでのみ適用されるSRPに関しては、彼の著書Robert C. Martin（私が知っている限りでは、彼がコンセプトを思いついたとしても普及させた）

クリーンコード、ページ。138：「単一責任原則（SRP）では、クラスまたはモジュールには、変更する理由は1つだけでなければならない」と述べています。

アジャイルの原則、C＃のパターンと実践、116ページ：「[...]結合を、モジュールまたはクラスを変更させる力に関連付けます。」

強調鉱山。

でAPPP彼は、SRPについてのより大きな長さで話し、クラスレベルでほぼ完全に焦点を当てました。彼はクラスレベルに焦点を当てているようですが、原則はモジュールや他のより高いレベルの構成体にも向けられていると感じています。

そのような理由で、あなたがあなたの質問で提案するように、私はクラスレベルでSRPをSoCとして認定しません。

— ジル
ソース

したがって、SRPをより高いレベルで適用できると仮定すると、SRPとSoCの違いは、SRPには単一の責任があり、SoCには密接に関連する一連の責任があるということです。

— user1483278

@ user1483278：まあ、私はSRPに非常に精通していますが、この質問を読んでいるときにSoCを初めて聞いたので、コメントで質問に答えることができません。セマンティクスから、SRPは1つの責任とSoC分離の懸念を持っていると思われますが、それは教訓的な答えであることがわかりますが、アプリケーションでは同様の結果が得られます。

— ジル

0

ここでは、これらの用語の違いを明確に説明する短いビデオを見つけることができます。https://www.youtube.com/watch?v=C7hkrV1oaSY

懸念の分離（SoC）。機能をできるだけ重複させずに、アプリケーションを個別の機能に分割します。（Microsoft）。

「懸念」=「個別の機能」=「個別のセクション」

「懸念」は高レベルと低レベルの両方で機能します

単一責任の原則は、すべてのモジュールまたはクラスがソフトウェアによって提供される機能の単一部分に対して責任を負うべきであり、その責任はクラスによって完全にカプセル化されるべきであると述べています。すべてのサービスは、その責任と密接に連携する必要があります。（ウィキペディアの定義）

「責任」=「変更する理由」

何を変える？「ソフトウェアが提供する機能の一部」= 基本単位

結論

単一責任原則は基本単位で機能します->低レベルで機能します

懸念の分離は、高レベルと低レベルの両方で機能します

SRPとSoCは連携して懸念事項を分離します。低レベルでもまったく同じです

— マルコ・クリスピノ
ソース

0

これらの原則の私の理解はここにあります。

懸念の分離（SoC） —ソフトウェアシステムをより小さなモジュールに分割することです。これらのモジュールのそれぞれが単一の懸念に責任を負います。この場合の懸念事項は、ソフトウェアシステムの機能またはユースケースです。モジュールには、明確に定義されたAPI（インターフェース）があり、その結果、システム全体の凝集力が高まります。水平と垂直の2つの主要なタイプがあります。

Single Responsibility Principle（SRP） —システムの各ビルディングブロック（クラス、モジュール、オブジェクト、さらには機能である場合もあります）には単一の責任のみが必要であることを示す設計原則です。ロバートC.マーティン。マーティンは、責任を変化の理由として説明しています。一般に、多くの、場合によっては無関係な機能を実行できるようにするのではなく、機能の単一部分を担当する単一のクラス/オブジェクトを用意して、このクラスを大きく結合します「神オブジェクト」と呼ばれます。

また、ブログの投稿でこれらの原則について詳しく説明しました。ご覧ください。

https://crosp.net/blog/software-architecture/srp-soc-android-settings-example/

— クロス
ソース