2

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.

  • Chain of Responsibility, maybe? – Matthias Meid Sep 25 '12 at 15:13
2

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.

  • 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
2

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.

0

In an object-oriented system, you'd normally place the behavior which varies according to its type in the type (AKA class) itself. But since Java doesn't allow you to add new methods to existing classes, unless you can use the toString() output of all or most of the classes in the XML converter and to reify the instances, you'll need to resort to another pattern.

Use the Method Overloading pattern to invoke the same semantics on different types. It usually makes the meaning clearer than lines of conditionals. Use it within the invoking object, or use the Visitor pattern to create the implementing class with the Method Overloading pattern to avoid the double-dispatch typical of Visitor implementations.

Thus, overloading methods like

String toXML(Integer anInteger)
{
  String   xmlResult;

  xmlResult = ...
  return (xmlResult);
}

String toXML(String aString)
{
  String   xmlResult;

  xmlResult = ...
  return (xmlResult);
}

String toXML(List aList)
{
  String    xmlResult;

  xmlResult = ...
  return (xmlResult);
}

You could then transform the values as

  for(Object eachValue : collection)
    xmlString += transformer.toXML(eachValue);

where collection would be the container for the data to be transformed, xmlString would be the receptacle for the XML output and transformer could be this or the visitor object.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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