Java – Design pattern for object conversion (java)

design-patternsjavaobject

I don't use design patterns very often, besides an occasional factory and MVC, and I want to start using them more.

I have a concrete case at hand that I would like your opinion on the use of design patterns in this case.

In my application I have to convert objects pretty often in different situations. I might have to convert a Hibernate POJO to a DTO, because I use GWT and Hibernate POJO's aren't serializable and can't be sent over the line.

In another situation I might need to convert Java objects to SolrInputDocument's for indexing by Solr.

I would like to know if I should use a design pattern for this. It seems that "object conversion" is a generic task that could be handled in a flexible/abstract way by a pattern, but I don't really see how.

Without patterns I would just create a separate class for each type of conversion, for example CourseToSolrInputDocument (Course is a Hibernate entity in my application). Or CourseToCourseDTO. Each of these conversion classes might have a single static method called convert() that takes the source object as input and returns the output object.

But that is not really a pattern, is it? So I started of on something with generics and created this class that implements the Converter interface. But is somehow feels silly tgo create a generic interface and I don't really see the advantage other than being able to congratulate myself on the use of generics.

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.
    }
}

So, the real question here is: is there a pattern that applies to generic object conversion and, what would be your approach and what are the advantages over using just a class-per-conversion type approach?

Best Answer

The Translator Pattern is what you're asking for.

But I suspect what you're looking for is a framework, more than a pattern. I believe Dozer is popular in the Java world.

Related Solutions

Better Understand the ‘Strategy’ Design Pattern

Your code will break when, e.g. ducks quack with a different sounds. The boolean will only lead to other booleans into really hairy if-statements.

The strategy pattern is simple though. Take in this instance the quack method and place it into it's own class or interface. An interface in php would be a class that does not contain any implementation other than methods that are stubs (i.e. nothing happens when you call them).

class Quackable {
    function quack() {}
}

That way you can create several quackable implementations:

class DuckQuack extends Quackable {
    function quack() {
        return "Quack!";
    }
}

class SilentQuack extends Quackable {
    function quack() {
        return ""; 
            // The decoy duck can't quack. It is silent.
    }
}

And because we did it strategy pattern wise, we can add more types of "quackery":

class DoubleQuack extends Quackable {
    function quack() {
        return "Quackety-quack!"
    }
}

The same can be applied to fly and swim methods for the Duck class. The way you implement a Duck class with a quackable would be like this (the quackable interface is supplied through the constructor, which is sort of how dependency injection works):

class Duck {
    protected $quackable;

    // The constructor
    function __construct($quackable) {
        $this->quackable = quackable;
    }

    function quack() {
        echo $this->quackable->quack();
    }
}

Implementing the mallard duck and decoy duck will be simple since you only need to supply what kind of quacks the duck should do:

class MallardDuck extends Duck {
    function __construct() {
        parent::__construct(new DuckQuack());
           // we construct the mallard duck with a duck quack
    }
}

class DecoyDuck extends Duck {
    function __construct() {
        parent::__construct(new SilentQuack());
           // we construct the decoy duck with a silent quack
    }
}

Using it all is simple:

$duck1 = new MallardDuck();
$duck2 = new DecoyDuck();

$duck1.quack(); // echoes out "Quack!"
$duck2.quack(); // echoes out "" (because decoy ducks don't quack)

I hope this all makes sense to you.

Java – When Business Object fields should not exactly reflect database columns

You may also think of an alternative representation. Consider the objects used by clients as an "interface objects". A DAO objects then may be used as a truly "business objects".

The business objects may (and usually have to) be tightly coupled with database to communicate with it in a most efficient way.

An interface objects, on the other hand, form an API. An API has it's own requirements, which don't necessarily suit well with what DAO provides:

A DAO object may expose the data, which should not be exposed to clients, such as passwords.
A DAO data representation may differ from what client needs. For example, the same password field can be hashed in database, while the client code operates with a non-hashed variant.
A DAO object may contain data not intended for direct manipulation by clients. Again, a password may be set during registration or checked for correctness, but not read.
An interface objects may often have additional requirements applied by the framework they used by, such as JSF or RMI.

Best Answer

Related Solutions

Better Understand the ‘Strategy’ Design Pattern

Java – When Business Object fields should not exactly reflect database columns

Related Topic