The question is simple. I need to convert the content of a bean into an other bean with different getters and setters. What's the right design pattern for doing this?
I think an adapter pattern is mainly referring to a mapping of a signature or interface to an other. Not a real mapping between objects.
Many people talks about "mapper" but I think this is not a design pattern.
So, is there actually a pattern for mapping an object to an other?
I'm not aware of any popular design pattern for object mapping.
I have been using Dozer framework for transfering the content from one bean to another.
It is simple to use and easily integrates with Spring.
Refer: http://dozer.sourceforge.net/documentation/gettingstarted.html
A great "design pattern" would be to not tightly couple the mapped objects to each other. A copy constructor, for example, means that if you edit the source class, you also have to edit the destination class, and that can cause all sorts of downstream issues in a large project. Think about it this way. A very frequent mapping is from UI data structures to back-end data structures. You should be able to scrap your UI and not have to change the back-end for a new UI. An MVC design pattern is frequently used for this sort of work.
The related pattern is Assembler where you assemble some object given the contents of another. Since writing assemblers can be tedious and error-prone, you can use an object mapping library to do the work for you.
One object mapper you might check out is ModelMapper, which I authored, that uses actual code to map properties, fields and methods, in a safe way.
There is a nice Translator pattern published by Microsoft. The tutorial is in C++ but it should be easy to convert to Java.
Here is a tutorial: http://richhewlett.com/2010/06/11/a-useful-entity-translator-pattern-object-mapper-template/
The general idea is you have a generic Translator abstract class, parametrized with the class types you want to translate between. The concrete implementations provide the "to" and "from" conversion methods.
This pattern has the advantage that it does not require coupling between the two classes in the conversion. It does this in a reusable, generic framework that won't clutter your code with one-off conversion decoupling logic.
I agree with Javakid, what you need is not a design pattern but a good solution to handle te conversion from one bean to another.
If you really need to name, that should something like dto pattern since you are using data transfer object. You can use a visitor to inspect all your bean tree while building the converted one.
so I would suggest using a framework or developping the mapping by yourself, it depends on the size of the graph. Dozer is goode solution to do it but it uses Reflection API all the way and hide the mapping code. So you won't be able to debug it easily, there are also few other runtime mapping library like Orika the best I know.
But, If you want to be able to see the code, debug it and have compiler feedback you can also use Selma.
Last thing, you can also report to this thread for a big picture of solutions to handle bean to bean mapping in java: any tool for java object to object mapping?
