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

ときどきファクトリーとMVC以外にデザインパターンを使用することはあまりないので、もっと使い始めたいです。

このケースでのデザインパターンの使用について、あなたの意見が欲しいという具体的なケースがあります。

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

別の状況では、Solrによるインデックス作成のためにJavaオブジェクトをSolrInputDocumentに変換する必要があるかもしれません。

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

パターンがなければ、CourseToSolrInputDocument（Courseはアプリケーションの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.
    }
}

したがって、ここでの本当の質問は、汎用オブジェクト変換に適用されるパターンがありますか？また、あなたのアプローチは何ですか？また、変換ごとのクラス型アプローチを使用するよりも利点は何ですか？

翻訳パターンは、あなたが求めているものです。

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