オブジェクトが自身の入力を解析する場合、SRPを破ると見なされますか？

Question

オブジェクトが自身の入力を解析する場合、SRPを破ると見なされますか？

例えば

class A 
{ 
    int x; 
    string y; 
    float f; 
    A(string x, string y, string f) 
    { 
     this.x = int.Parse(x); 
     if (this.x < 0 || this.x > 10) 
     { 
      throw new ArgumentOutOfRangeException(); 
     } 
     this.y = y; 
     this.f = float.Parse(f); 
    } 
} 

またはプライベートコンストラクタを持っているし、解析し、チェックの入力をしてAを返すのpublic staticメソッドを使用します。

int、string、floatを渡して解析するのではなく、他の場所で有効かどうかを確認してください。

Answer 1

これはシングル責任原則ですか？いいえ、基本的なオブジェクトを構築するために与えられたプリミティブ型を解析している例では、それが自分自身の責任であることをあなたが与えたサンプルコードでは感じません。 SRPは、ビジネスドメインが内部で動作することを前提に説明が簡単です。

以上のように、上記の構文解析はプリミティブ型で行われていますが、プリミティブ型の構文解析は、プリミティブ型の変換を容易にします。 SRPの目的は、そのようなコア機能を抽象化することではなく、コードの設計に単一の責任があることを保証することです。たとえば、レコードをデータベースに保存するときに、生データを収集し、それを別のテーブルにマップし、エントリを確認する電子メールを送信する関数を記述することができます。これはSRPを破っています。このような例で私たちはどうやってこれを避けるのですか？リポジトリ・パターンなどを使用してデータベースの問題を抽象化し、電子メール通信を管理するための別のクラスを用意します。おそらくは依存性注入を使用して、ソリューション内でこれらのコンポーネントを容易に交換できます。私は真剣に基本的な型のすべての基本的な解析を抽象化しようとしますか？

絶対にありません。

全体のコンセプトが「変更する理由」です。コードデザインに変更が必要な理由が複数ある場合は、SRPが破られています。与えられた例では、電子メールが変更された場合や、生データや異なるテーブルへのマッピングの場合、3つ以上の異なる理由でコードを変更する必要があります。

あなたのコンストラクタまたは関数は、理想的には正しい型を受け入れる必要がありますが、これを行うことができない理由があるかもしれませんが、正しい型で値を指定できる場合は解析を避けるべきです。

最後に追加したいこと：多くの開発者が、プリミティブ型に関するこのような問題を解決し、オブジェクトの解析と構築を行い、SRPなどの設計原則が破られないようにしようとしています。彼らは細心の注意を払って問題を調べることに時間を費やし、その結果、より大きなドメイン設計の問題を逃しました。より大きな画像を確認し、アプリケーションのアーキテクチャを見失わないようにしてください。このようなことを心配することはお勧めしません。アプリケーションを設計する上で大きな問題を抱えていないという罠に陥ることはありません。

Answer 2

（データフォーマットに関連する変更の軸を導入するため）解析が責任であることに同意する場合、唯一の問題はclass Aに別の責任があるかどうかです。 class Aに構文解析とは無関係の追加ロジックがある場合、それは別の責任を示します。

すでにclass Aが入力を解析して検証していると考えると面白いです。検証は、ビジネス要件に関連する第2の変化の軸になる可能性があります。これはSRPに違反していますか？これは、これら2つの軸が独立して変化する可能性がどの程度あるかによって決まります。