Translator Pattern. Know Your Patterns :)




This pattern is really simple. It provides a method to convert from a representation to another. The same concept can be represented in many ways. Sometimes you have to “import” and “export” representations, so you have to provide a proper encapsulation for the logic that converts from one object to another.

Why would you need to do that? In my personal experience I have used it to convert instances of “legacy” clases that are not too well designed. It happens that a lot of logic already exists in the solution that work with those clases, so redefining them would be really expensive. The brand new features use better an more robust clases. For newer parts, I use a translator to perform a one time time conversion. When a legacy part of the application needs a “new” instance, I request a conversion to the old class instance.

It can be seen as a pattern similar to Adapter or Builder. But Adapter translates interfaces and provide a “wrapper” that interacts between the outer world and the wrapped classes along all its lifecycle. Builder creates complex objects. It’s a similar pattern, but I don’t feel it’s the same as the builder doesn’t translate, it builds up an instance.

What do you think about it? Do you see a Builder here? Smile

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s