データベースに自らを保存するオブジェクトカップブルは、クラスの結束を台無しにしますか？

Question

オブジェクト指向のデザインの観点から言えば、オブジェクトにデータベースに自分自身を保存する機能を与えると、クラスの結束を台無しにすると思いますか？

想像：

Product p = new Product() 
          {
           Name = "Joy Rider", 
           Price = 100, 
           Currency = "USD"
          };

この製品Pをデータベースに保存することは、この方法で行う方が良いと思いますか：

 p.Save();

またはある意味で次のようなもの：

 ProductServices.SaveProduct(p);

どう思いますか？

Answer 1

単一の責任の原則に干渉します。例の製品クラスの目的は、その製品とその製品の操作を表すことです。データベースとの対話は、クラスの責任の中核部分ではありません。

Procestervicesクラスを使用すると、コードの保守性が向上します。データベース内のオブジェクトを保存するためのロジックが変更されたと仮定します（これができます）システム内のすべてのエンティティクラスを変更しますか？

Answer 2

データベースに自らを保存できるオブジェクトは違反します SRP （単一の責任の原則）。

持続性はすべてそれ自体責任であり、専用のクラスによって処理されるべきです。

これは、凝集度が低いことに加えています。持続性に関係しているメンバーは、持続性に対処しないクラスの方法で使用しておらず、使用しないメンバーとは関係ありません。

Answer 3

の面では オブジェクト指向のデザイン その場合にのみ、保存方法が一部であることに何の問題もありません 製品. 。それは実際には、オブジェクト指向のデザインの世界で好ましい方法です。そして、純粋なOOの観点からは、オブジェクトよりも機能的であるため、バラバラになりたくないでしょう。

ただし、高レベルのモジュールが低レベルモジュールに依存してはならないと言う依存関係の反転原則を信じている場合。その後、保存方法が適切ですが、抽象接続タイプをパラメーターとして使用する必要があります。これにより、保存方法を含む素敵なオブジェクトモデルが提供されますが、接続のタイプを知らないでしょう。