Object Conversion Pattern

Question

I have several different classes coming from external sources (unmodifiable) that represent the same concept. For example `Address`. I have `com.namespace1.Address` (with fields `houseNum`, `street`, `city`), `com.namespace2.Address` (with fields `h`, `s`, `c`), `namespace3.com.CoolAddress` (with fields `house_num`, `street`, `city`). The problem is that certain web services I use require certain Address object types so I am required to create a `com.namespace1.Address` given a `namespace3.com.CoolAddress`. The fields are easy enough to map but I'm looking for a pattern on how to do it. From my point of view, an instance object `AddressConverter` doesn't make sense as there is no state (only behaviour) and when classes only have behaviour it boils down to static methods in a utility class. In the long term, anytime I need to map new objects to one another, I have one place to add/modify/remove methods. How it's done might change, but I know where the code sits (in once place) and can…

Accepted Answer

I think what you're looking for is a factory class. The factory pattern is used when you need to be able to instantiate one of several related classes, to be determined by the factory, not the developer.

See http://en.wikipedia.org/wiki/Factory_method_pattern

You're right to try to keep all this business logic in one place instead of doing ClassOne.toClassTwo(), ClassOne.toClassThree(),...

The most flexible way I can think of implementing this (but not the easiest by far) would be to have the factory start with a simple class with only basic common methods in it, and add handlers to a Hashtable or other container. That way you don't need concrete implementations of every possible combinations of features.

Of course it would be quicker to have a concrete implementation for each possible address variant, but there would be a fair amount of duplicated code, and it would be a little harder to add new address class types.

Object Conversion Pattern

Solution

Problem