4

オブジェクト指向設計の観点から言えば、それ自体をデータベースに保存する機能をオブジェクトに与えると、クラスのCOHESIONが台無しになると思いますか？

想像：

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

この製品pをデータベースに保存する方が、次のように行う方がよいと思いますか。

 p.Save();

または次のような方法で：

 ProductServices.SaveProduct(p);

どう思いますか？

4

3 に答える 3

8

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

永続性はそれ自体が責任であり、専用のクラスで処理する必要があります。

これは、凝集度が低いことに加えて、永続性に関係するメンバーは、永続性を処理しないクラスのメソッドで使用されないメンバーとは関係がありません。

于 2010-12-07T15:09:26.300 に答える
5

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

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

于 2010-12-07T15:09:45.623 に答える
2

オブジェクト指向デザインに関しては、SaveメソッドがProductの一部であることに何の問題もありません。これは、実際にはオブジェクト指向デザインの世界で推奨される方法です。そして、純粋なOOの観点からは、オブジェクトよりも機能的であるため、分解したくないでしょう。

ただし、高レベルのモジュールが低レベルのモジュールに依存してはならないという依存性逆転の原則を信じている場合は、その場合、Saveメソッドが適切ですが、パラメーターとして抽象接続タイプを使用する必要があります。これにより、Saveメソッドを含む優れたオブジェクトモデルが得られますが、接続のタイプについての知識はありません。

于 2010-12-07T15:25:36.587 に答える