4

私は最近、それらがSRPを明らかに壊す可能性があることを説明する記事を読みました。セッターとゲッターで単一のクラスを長い間書いていたので、今は完全に混乱しています。

また、これを見つけましたが、 SRPとは関係ありません

一見すると、getter と setter の両方が、現在のクラスにのみ「属する」ロジックを持っているため、 Single Responsibility Principleを破ることはありません。彼らは、単一の目的を「果たす」クラスメンバーにアクセス/書き込みできます。罰金。

しかし、待ってください。最初に基本的な用語を定義しましょう。

データ アクセス = セッターとゲッターの両方

データ処理= データ処理、操作CRUD、検証など

もしそうなら、1 つのクラス内に 2 つの異なる責任があり、SRPを破ることになります。

ここで、SRP を壊さないようにするために、データ アクセスとデータ操作を異なるクラスで定義するとします。

class DA { // <- Data Access
  public string getName() {
      return this.name;
  }

  public string setName(name) {
     this.name = name;
  }
}

class DataHandler {
     public DataHandler(da) { // <- Inject an instance of DA
         this.da = da;
     }

     public bool validate() {
          // validation stuff
     }
}

上記の SRP に違反していないため、問題ないようです。しかし、ここでは DA クラスにセッターとゲッターが 1 つしかありません。

今質問：

1) SRP を壊さないように、setter と getter が 1 つしかない場合でも、常に別の DA クラスを作成する必要がありますか?

2) セッターとゲッターは本当にSRPを壊しますか? また、クラス内で決して使用すべきではありませんか?

3) もしそうなら、依存性注入は常に答えです!?

4

1 に答える 1

2

セッターとゲッターは SRP を壊しますか?

セッターとゲッターは重要ではありません。SRP の要点は、クラスは 1 つの責任しか持たないということです。

ドメイン オブジェクトを表すことは大きな責任です。これを行うオブジェクトは、多くの場合「データ オブジェクト」と呼ばれます。言語の設計や規則により、データ オブジェクトにセッターとゲッターがあるのはよくあることですが、それら自体が別の責任を負うわけではありません。彼らはただ配管しています。

永続ストアにデータ オブジェクトを出し入れすることも、大きな責任です。これを行うオブジェクトは、多くの場合、"データ アクセス オブジェクト" (DAO) と呼ばれます。データ オブジェクトではないDAOは、それが管理するデータ オブジェクトの型の属性のセッターとゲッターを必要としない非常に恐ろしいフレームワークを想像することはできますが、おそらく必要ありません。DAO と同様に、データ オブジェクトを操作 (表示、シリアライズとデシリアライズ、計算の実行など) し、それ自体がデータ オブジェクトではない他の種類のオブジェクトは、おそらくデータ オブジェクトをミラーリングするセッターとゲッターを必要としません。

したがって、セッターとゲッターがあるということは、オブジェクトがデータ オブジェクトであることを示しています。それがデータ オブジェクトであり、DAO でもある場合、または他の大きな責任がある場合、おそらく SRP に違反しています。

補足：検証について言及しています。一般的なアプリケーションでは、少なくとも個々のデータ オブジェクトの検証は、データ オブジェクト自体に属します。これは、ドメイン オブジェクトを表すことと、ドメイン オブジェクトの属性間の個々の正確性と関係を強制することは、ほぼ同じ責任であるためです。

セッターとゲッターが 1 つしかない場合でも、常に別の DA クラスを作成する必要がありますか?

一般的に、はい。ポイントは属性の数ではありません。要点は、表現とアクセスは 2 つの異なる責任であり、異なるクラスに属しているということです。

一般的なアプリケーションには多くのドメイン オブジェクトがあるため、ドメイン オブジェクトをアクセスから分離することが理にかなっている場合は、すべてのドメイン オブジェクト (単一属性のものであっても) に対して一貫して行うことが理にかなっています。

依存性注入は常に答えですか?

アーキテクチャとフレームワークによって異なります。不変のデータ オブジェクトと、メソッドがそれらをパラメーターとして受け取る DAO がある場合があります。そこには DI はありません (ただし、DAO を使用する上位レベルのコンポーネントに DAO を挿入することはできます)。データ オブジェクトまたは DAO への参照を持つデータ オブジェクトでインスタンス化された DAO があるかもしれません (どちらのパターンも見たことがありますが、嫌いです)。そこでDIが必要になるかもしれません。いずれにせよ、残りの議論とはあまり関係がありません。

于 2016-02-14T02:21:32.577 に答える