Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For converting a Java object model into XML I am using the following design:

For different types of objects (e.g. primitive types, collections, null, etc.) I define each its own converter, which acts appropriate with respect to the given type. This way it can easily extended without adding code to a huge if-else-then construct.

The converters are chosen by a method which tests whether the object is convertable at all and by using a priority ordering. The priority ordering is important so let's say a List is not converted by the POJO converter, even though it is convertable as such it would be more appropriate to use the collection converter.

What design pattern is that?

I can only think of a similarity to the command pattern.

share|improve this question
Chain of Responsibility, maybe? – Matthias Meid Sep 25 '12 at 15:13

I second Awemo's answer; this sounds like the Strategy Pattern, where algorithms that do similar things given different inputs or expected outputs are encapsulated, and then the proper algorithm can be chosen at runtime given knowledge of the data being input.

One comment mentioned "Chain of Responsibility"; this is related but slightly different and may incorporate a Strategy pattern. Basically, one at a time, in a pre-determined or dynamic "most likely first" order, the set of inputs is given to one of the encapsulated "strategies". That strategy has the knowledge to "decide" for itself whether it can do anything with the inputs. If it can, it may partially or completely process the inputs, and signals to the parent "supervisor" whether it thinks any further processing is needed. If it can't, it simply flags that fact. The supervisor then finds the next most likely algorithm to handle processing or further processing, until something signals to the supervisor that the inputs have been completely processed.

share|improve this answer
To my mind the algorithm in strategy put a real emphasis on the solving aspect. I mean of course, everything you write in somewhat of an algorithm, but I only call some methods in each Converter. What about the builder pattern, wouldn't this be more appropriate? – RevMoon Sep 25 '12 at 16:09
When you say you only call some methods in each converter, I have the feeling that these methods are superfluous. From the little I could pick up on the builder patterns, it is solely for creating objects but the strategy pattern implements algorithms depending on the context. In your case, the context would be the object type to be converted. – Awemo Sep 25 '12 at 16:25

It sounds like the strategy design pattern.

a software design pattern, whereby an algorithm's behaviour can be selected at runtime. Formally speaking, the strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it...

For instance, a class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed. The validation strategies, encapsulated separately from the validating object, may be used by other validating objects in different areas of the system (or even different systems) without code duplication...

You have different algorithms for similar things.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.