Geek Answers Handbook

Do static domain model translators need?

In many of the projects I have worked on, we often have many classes that display content from one domain model to another. For example, from the created WSDL model for a specific project.

eg

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

it can also be a non-static method, and the service level can have a mapper object field instead of calling a static method:

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

I believe that both methods are used a lot, but:

  • is one solution more efficient in any way?
  • Are any of the solutions considered best practice?
+6
source share
2 answers

"Is one solution more efficient?"

Define "effective." If "effective", you mean the time and memory requirements of the processor, then the "approximate" approach will never be more effective than the "static" approach; in the best case, it can be as effective as the static approach, and the difference depends on the frequency of the creation of the object, read: how many times you are going to create an instance of the "instance".

"Are any of the solutions best?"

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

  • If a matching operation requires maintaining state, such as dependency on other services / mappers / whatnot, then using the instance approach makes more sense. One thing you don’t want to get into is the world in which your application design consists of single elements that depend on each other. Use the instance approach, preferably using an automated wiring tool such as Spring Framework or CDI.

  • If the matching operation does not require state, and you have extremely high confidence that it will never require state in the future, then use the "static" approach - if you don’t already have an automatic posting facility, in this case you can also select " example with automatic wiring and to ensure that if the display operation requires status in the future, you do not have to change the design much.

+4
source

There are other things to consider: Your code can be verified. Mappers are used as collaborators, so should unit testing using a mapper focus on behavior (i.e., a converter is used when expected)? Is a static class more than one place and subject to the race condition because the conversion method accepts a mutable object (remember, static classes without static are still subject to the race condition when using a mutable object referenced by two different threads at the same time)? Does a stationary object actually share the life cycle using this object?

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

0
source

More articles:


All Articles