web-dev-qa-db-ja.com

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

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

b）a）に対する回答が「はい」の場合、SoCが適用されますクラスレベルの同義語[〜＃〜] srp [〜＃〜]？

ありがとうございました

design-patternssingle-responsibility
19
user1483278

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

Separation of Concernsは、コードが他のいくつかのクラス/システムに密結合されていないことに関するものです。コードでインターフェイスを使用すると、クラス/システムを緩やかにコードに結合できるため、非常に役立ちます。これのプラス面は、コードの単体テストも簡単になることです。これを達成するのに役立つ多くの（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メソッドに配置する必要があるかどうか、議論することもできます。これはあなたが自分で決めるべきことです。私には、このメソッドはあまりにも多くのことをやっているように見えます。

13
Jan_V

SRPがクラスレベルでのみ適用されていることについては、彼の著書でロバートC.マーティン（私が知る限り、彼がコンセプトを思い付かなかったとしても彼が普及している限り）は次のように述べています。

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

C＃のアジャイルの原則、パターン、および実践、116ページ：「[...]と凝集力をmodule、またはクラス、変更します。」

Emphasis mine。

[〜＃〜] appp [〜＃〜]で、SRPについてより長く話し、ほぼ完全にクラスレベルに集中しました。彼はクラスレベルに焦点を当てているようですが、原則はモジュールやその他のより高いレベルの構造にも向けられていると感じています。

このような理由から、質問で提案されているように、クラスレベルではSRPをSoCとして認定しません。

2
Gilles

これらの原則についての私の理解は次のとおりです。

懸念の分離（SoC）—ソフトウェアシステムを小さなモジュールに分割することです。これらのモジュールのそれぞれが単一の懸念の原因です。この場合の問題は、ソフトウェアシステムの機能または使用例です。モジュールには明確に定義されたAPI（インターフェース）があり、その結果、システム全体が非常にまとまりのあるものになります。水平と垂直の2つの主要なタイプがあります。

単一責任原則（SRP）—各構成要素（クラス、モジュール、オブジェクト、またはシステムの機能）は単一の責任のみを持つべきです。ロバート・C・マーティン。マーティンは、責任を変更する理由として説明しています。一般に、多くの、場合によっては無関係な機能を実行できるのではなく、機能の単一の部分を担当する単一のクラス/オブジェクトを用意し、このクラスを大きくて密結合にする方がはるかに優れています。 「神オブジェクト」と呼ばれます。

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

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

0
CROSP

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

懸念事項の分離（SoC）。機能の重複をできるだけ少なくして、アプリケーションを個別の機能に分割します。 （マイクロソフト）。

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

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

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

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

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

結論

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

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

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

0
Marco Crispino