なぜいくつかのパターンはooデザインで別々のデータクラスを持つクラスを持っています

Question

私はちょうど私の古いooデザインブックのいくつかと私がかなり従わないものを読んできました。

もし私がリポジトリパターンのようなものを使っているとすれば、

すなわち：

interface ICarRepository { 

     IEnumerable<car> GetCarCollection(); 

    } 

    class MsSqlCarRepository : ICarRepository { 

     IEnumerable<car> GetCarcollection(){ ................ }; 

    } 

    class car { 

     int CarId; 
     string CarName; 

    } 

上記のコードは、＃cはおおよそですが、本当に関連イマイチ。

上記はうまくいきますが、一般的に私が見ているものですが、私が読んだ本はすべて、オブジェクトがメソッドとプロパティを組み合せていることを一般的に述べています。

だからの線に沿ってより多くのことがインタフェース部はずのを無視：

class car { 

     int CarId; 
     string CarName; 

     IEnumerable<car> GetCarcollection(){ ................ }; 

    } 

????

Answer 1

あなたのCarクラスを変更することなく、PostgresSQLCarRepositoryのような別のリポジトリに置き換えることができるという考えがあります。

リポジトリクラスを別々のライブラリに分けて、それを依存関係注入によって読み込むことができます。

もしあなたが複数のlibary dllをコンパイルすると、postgresを話す人、mssqlを話す人、XMLを話す人、あなたの車のクラスを再コンパイルすることを気にせずにあなたのコードを使うことができます。コメント

後

--editは質問がよりあるように思われる追加のコメントの後、なぜこの本当の世の中のデザインパターンはオブジェクト指向の基本的な原則に従わないように思われるのですか？

簡単な答えは、OOの基本原則に従うということです。

長い答え...

OOの基本的な考え方は、（これは、継承、ポリモーフィズムなどの大量に行かなくても、過度に単純化され）まとめてグループ化することを特定のエンティティに関するプロパティのコレクションです特定のエンティティを単一のクラスに操作するメソッドなどがあります。

GetCarCollection（）メソッドは、1つの車のインスタンスには適用されません。これはリポジトリに適用されます。これは、リポジトリに複数の車の回収を依頼しているためです。しかし、Start（）のようなメソッドは、その自動車のインスタンスに具体的に適用されるため、車に対するメソッドとなる可能性があります。

その上

あなたは、さらに読み取り専用かもしれない性質を持っていて、通常、その代わりに、あなたは

public class car { 

    private int _carId; 
    private string _carName; 
    private int speed=0; 

    public Car(int carId) { 
    this._carId=carId; 
    } 

    public int CarId { 
    get { return this._carId; } 
    } 

    public string CarName { 
    get { return this._carName; } 
    set { this._carName=value; } 
    } 

    public int Speed { 
    get { return this._speed; } 
    } 

    public void Accelerate() { 
    if (this._speed<91) this._speed++; 
    } 
} 

public class MsSqlCarRepository : ICarRepository {  

    public MsSqlCarRepository(SqlConnection conn) {.....} 

    IEnumerable<car> GetCarcollection(){ ................ } 

}  

public class XmlCarRepository : ICarRepository {  

    public XmlCarRepository(string FileName) {.....} 

    IEnumerable<car> GetCarcollection(){ ................ } 

}  

あなたが持っていないことがありました例があるかもしれないクラスのインスタンス自体にのみアクセスできるようにバッキングフィールドを非表示します非常にOOのように思えましたが、それは単純化されていたので、それ以上でした。オブジェクトの詳細と複雑さのレベルが増すにつれて、これが実際にどのようにOOのアプローチであるかを理解し、Cの構造とマネージャーのアプローチから乖離し始めます。

Answer 2

これは、コードのさまざまな部分のレイヤー間の結合についてです。これらのドメインモデルで実行できる操作/コントラクトからドメインモデルを分離することで、他のコンテキストでこれらのドメインモデルをより簡単に再利用することができます。例えば、誰かがGetCarcollectionよりも、このCarモデルで他の操作を定義したいとします。この場合、彼は別のリポジトリインターフェイスを作成し、このドメインモデルを変更する必要はありません。一方、Carオブジェクト内にGetCarcollectionメソッドを定義した場合、このモデルの他の消費者は、自分のメソッドを気にしないかもしれないが、自分のメソッドを使用したいと思うので、満足できないでしょう。

Answer 3

車のコレクションは車の本質的なものではありません。ガレージや駐車場には車のコレクションがあります。

Answer 4

車はカーレポジトリではありません。それ以外の場合は、車を持って車を取得する必要があります。車を表すすなわちにタイプの役割である（

GetCarCollection は静的メソッドかもしれないが、それは、あなたがモックまたはリポジトリを注入することができないだろう、との懸念の分離を表すものではありません。それともに車を持っていくのですか？？）

ここで線を引く部分は主観的なもので、プロジェクトの要件によって異なる場合があります。