0

例として、GPS および地理 (GIS) エンティティのドメインを考えてみましょう。

意味のある地理的エンティティ (ポイント、パス、地域) を任意のプログラミング言語のクラスとしてモデル化します。これらのクラスは、これらのエンティティの概念的な「実装不要」な表現になります。

一方、これらの機能を多かれ少なかれ同じ意味で保存するファイル形式はたくさんあります。GPS ドメインで最も一般的なファイル形式は、GPX、KML、ShapeFile、WellKnownText などです。

次に、プロパティ、プロパティなどGpsFeatureCollectionを含むクラスを作成したいとします。また、 、、(およびそれぞれの ) などのクラスを実装します。PointsPathsGpsReaderKmlReaderShapeFileReaderWriter

質問は：

OOAD のベスト プラクティスは次のとおりです。

  1. クラスGpsFeatureCollectionをインスタンス化する必要がありますか?FileFormat(Reader/Writer)
  2. クラスの代わりにメソッドGpsFeatureCollectionを実装する必要がありますか?Read/WriteFromFormat
  3. 各ファイル形式リーダーに空の をインスタンス化し、GpsFeatureCollectionファイルから読み取ったデータを入力してから、入力されたオブジェクトを戻り値として渡すようにしますか?
  4. との間の依存関係を回避するためのメディエーター クラスがFileFormatClassありObjectModelClassますか?
  5. 上記のどれでもない？
  6. 「まあ、場合による……」

私は「正しいこと」をすることに本当に興味があります。当面の計画は Python を使用することですが、おそらくこれは他の言語でも問題になるでしょう。これにより、現在、私のペットプロジェクトで「分析麻痺」が発生しています...

4

1 に答える 1

1

read()これは、リーダーとライターのインスタンスをandメソッドに渡す私write()の見解です。これは、適切なレベルの分離を実現しているように見えますが、さまざまなリーダーとライターを選択する柔軟性を提供します。

コードは Java に似た構文を使用します

インターフェイスを宣言します。 、 などの Reader複数の実装を想定します。KMLReaderShapeFileReader

interface Reader {
   GpsFeatureCollection read();
}

インターフェイスを宣言します。 、 などのWriter複数の実装を想定します。KMLWriterShapeFileWriter

interface Writer {
   void write(GpsFeatureCollection c);
}

ジョブを実行するためのパラメーターとしてそれぞれのインターフェイスを受け入れるGpsFeatureCollectionクラスreadとメソッドを宣言しましょう。write

class GpsFeatureCollection {

    ...

    public static GpsFeatureCollection read(Reader r) {
       return r.read();
    } 

    public static void write(Writer w) { 
        w.write(this);
    }

}

さまざまなリーダーとライターを使用した使用例。

// Reading data
GpsFeaureCollection data = GpsFeatureCollection.read(new ShapeFileReader("/tmp/shapefile"));

// Writing data
data.write(new KMLWriter("/tmp/kmlfile"));
于 2013-07-14T13:09:39.423 に答える