Design suggestions for converters in Java

Question

I'm trying a set of converters which will convert an object to some older form. And there are different objects which are converted. By older form I mean changing the values of some fields and in case of file objects making changes such that the new file complies to older schema, etc.

A convertObjectAToOldFormat(A a);
B convertObjectBToOldFormat(B b);

Should I create class for each of this converters? Or Can I put all of them in a single class and expose the interface to clients? Or is there any design which will handle this better?

Language used is Java

Answer 1

Which class should know how to convert a new A to a legacy A?

Maybe it's the A class itself which has this knowledge. It may know how new and legacy values are mapped, which fields should be added or removed, etc. In this case the following approach seems quite natural:

A legacyA = a.toLegacy();

The benefit of this approach is consistency: it's similar to toString() method which converts, say, an integer or a double to a string. The interesting part here is that while toString of an int creates an instance of a completely different type (string), toLegacy returns an instance of the same type.

The drawback is the violation of SRP principle, as well as the fact that the conversion code (especially to some legacy forms) is polluting the class. If the conversion logic is complex and has few things to do with A itself, it makes sense to move this code to a separate class.

This situation is very similar to factory pattern and abstract factory pattern: when the logic required for creating instances of a class becomes too complex to remain in the class itself (in a form of a static method), then factory pattern is used. If there are many similar entities, an abstract factory pattern starts to be valuable.

In a similar way, you can have your abstract converter class, and the concrete classes which deal with the conversions of different business entities:

abstract class ConverterToLegacy<T>
{
    public T Convert(T businessEntity);
}

class ConverterToLegacyA implements ConverterToLegacy<A>
{
    public A Convert(A a)
    {
        ...
    }
}

class ConverterToLegacyB implements ConverterToLegacy<B>
{
    public B Convert(B b)
    {
        ...
    }
}

Answer 2

You could have a factory which provides the correct adapted object.

Exposing a series of classes or a single class with multiple methods assumes that you have some knowledge before hand of the system. Another (problematic, I think) issue is that by exposing all the adapters you are giving the caller (client) complete control over which adapter gets called.

This, in my opinion, could cause some issues since someone might try and find a way (on purpose of by accident) around some internal mechanisms you might have (validation comes to mind) which could be problematic.

Having 1 endpoint which is exposed to the user and having some logic which does everything which needs doing provides you with more control.

Answer 3

You seem to be asking for two different things here:

1. changing the values of some fields

Are you referring to how you need to normalize values' formattings ("yyyy-MM-dd" to "ddMMyy") or possibly even data types here (BigDecimal to int)? If so, I'll suggest creating a conversion class to handles these, so that you can safely eliminate both the conversion and API pollutions within your class.

2. making changes such that the new file complies to older schema

Wells, serialization libraries and how they handle schema resolution came to my mind immediately, such as how Apache Avro does it... If you can consider your objects/data files (hmms a bit of a stretch though for the latter) to be handled as a form of serialization, then these libraries are definitely worth a look here, because the problem is most likely solved for you. For the full low-down on schema resolution comparisons, this article is a great, if slightly overwhelming, read too.

edit Given the risk of link rot, I'll just quote the relevant parts of the article here...

4. Then you find that people are stuffing all sorts of random fields into their objects, using inconsistent types, and you’d quite like a schema and some documentation... hey, if you had a schema, you could avoid storing objects’ field names, and you could save some more bytes!

Once you get to the fourth stage, your options are typically Thrift, Protocol Buffers or Avro. All three provide efficient, cross-language serialization of data using a schema, and code generation for the Java folks.

In real life, data is always in flux. The moment you think you have finalised a schema, someone will come up with a use case that wasn’t anticipated, and wants to “just quickly add a field”. Fortunately Thrift, Protobuf and Avro all support schema evolution: you can change the schema, you can have producers and consumers with different versions of the schema at the same time, and it all continues to work. That is an extremely valuable feature when you’re dealing with a big production system, because it allows you to update different components of the system independently, at different times, without worrying about compatibility.