Should domain model mappers be static?

Question

In many of the projects I have worked on we often have a lot of classes that map content from one domain model to another. For example from a WSDL generated model to a project specific one.

for example

public class FooBarContentMapper {
    public static Foo fromWsToDomain(FooType fooType) {
        ...
    }
}

this can also be a non-static method and the service layer can have a mapper object field instead of calling the static method:

public class FooBarContentMapper {
    public Foo fromWsToDomain(FooType fooType) {
        ...
    }
}

I find both ways used a lot, but:

• is one of the solutions more efficient in any way?
• are any of the solutions considered best practice?

Answer 1

"Is one of the solutions more efficient in any way?"

Define "efficient". If, by "efficient", you're referring to CPU time and memory requirements, then the "instance" approach can never be more efficient than the "static" approach; at best, it can be as efficient as the static approach, and the difference depends on the frequency of object instantiation, read: how many times are you going to instantiate the "instance" approach.

"Are any of the solutions considered best practice?"

No. The "best practice" here is to match your design to your requirements.

• If the mapping operation requires maintaining state, such as dependencies on other services/mappers/whatnot, then going with the "instance" approach makes more sense. One thing you don't want to get into is a world where your application's design consists of singletons that depend on each other. Use the "instance" approach, preferably using an auto-wiring facility such as the Spring Framework or CDI.

• If the mapping operation requires no state, and you have an extremely high confidence in that it will never require state in the future, then use the "static" approach - unless you already have an auto-wiring facility at hand, in which case, you might as well choose the "instance" approach with auto-wiring and guarantee that, if the mapping operation requires state in the future, you won't have to alter your design much.

Answer 2

There are other things to consider: Is your code testable. Mappers are used as collaborators so unit testing the object using the mapper should focus on behavior (i.e is the mapper being used when expected) ? Is the static class used in more than one place and subject to race condition because the transform method takes a mutable object(remember, stateless static classes are still subject to race condition when taking a mutable object that is referenced by two different threads at same time)? Does the static object actually share its life-cycle with the object using it?

If the answer is yes to any of these, you should consider switching to instance.