web-dev-qa-db-ja.com

オブジェクト変換の設計パターン（Java）

たまに工場やMVC以外にデザインパターンをあまり使用していません。もっと使い始めたいと思います。

この場合のデザインパターンの使用について、具体的な事例をお伺いしたいと思います。

私のアプリケーションでは、さまざまな状況でかなり頻繁にオブジェクトを変換する必要があります。 GWTを使用しているため、Hibernate POJOをDTOに変換する必要がある場合があります。HibernatePOJOはシリアル化できず、回線経由で送信できません。

別の状況では、Solrによる索引付けのためにJavaオブジェクトをSolrInputDocumentに変換する必要があるかもしれません。

これにデザインパターンを使用する必要があるかどうか知りたいのですが。 「オブジェクト変換」は、パターンによって柔軟で抽象的な方法で処理できる一般的なタスクのようですが、実際の方法はわかりません。

パターンがなければ、変換の種類ごとに個別のクラスを作成するだけです。たとえば、CourseToSolrInputDocument（コースはアプリケーションのHibernateエンティティです）。またはCourseToCourseDTO。これらの各変換クラスには、convert()と呼ばれる単一の静的メソッドがあり、ソースオブジェクトを入力として受け取り、出力オブジェクトを返します。

しかし、それは実際のパターンではありませんね。だから私はジェネリックで何かを始め、Converterインターフェースを実装するこのクラスを作成しました。しかし、どういうわけか愚かなtgoがジェネリックインターフェイスを作成しているように感じ、ジェネリックの使用について自分自身を祝福することができること以外に、私は本当に利点を見ません。

public class CourseToSolrInputDocument implements Converter<Course, SolrInputDocument>         {
    @Override
    public void convert(Course source, SolrInputDocument destination) {
        //To change body of implemented methods use File | Settings | File Templates.
    }
}

だから、ここでの本当の質問は、一般的なオブジェクト変換に適用されるパターンはありますか？そして、あなたのアプローチは何であり、変換ごとのクラスタイプのアプローチだけを使用するよりも優れている点は何ですか？

javadesign-patternsobject
21
Julius

Translator Pattern はあなたが求めているものです。

しかし、あなたが探しているのはパターンではなくフレームワークだと思います。 Dozer はJavaの世界で人気があります。

18
pdr