I have a Java EE application which takes input data from a JAX-RS-Resource, passes them through the application and at some point it calls a SOAP client which classes gets generated. But the problem is, that I have multiple clients which represent different start times. There's a "ClientParameters" class which assigns the input data to the client data. But the problem is: I have this class almost exactly the same 4 times. They mostly do assignments and converting. So it looks like this:
So the idea is to replace the InputData parameter with a "ClientValues" class which already holds the correctly formatted data, so that the ClientParameters only calls getters, nothing more.
First I thought I'd create a "ClientValuesAdapter" which simply contains a static method which creates the "ClientValues". Inside we have lots of pure functions that can be tested easily. Something like this:
A friend pointed out that this is not really an Adapter but a Factory. I agree with this mostly, but most definitions on the web use inheritance. I don't see any advantage in using inheritance or non-static methods here. But I don't want to use any naming which may confuse other developers. Most patterns seem to be coupled with inheritance which is sometimes just not necessary.
What would you call it? Is it an Adapter, a Factory or even something else? I was thinking about calling it ClientValuesMapper instead.
I was also thinking about changing it so it conforms the Adapter definition. But I think pure functions are better to test.
Not just you. But I can't change it so I have to live with it. :-)
Okay, good point.
But still: Would you call this a factory?
I was already thinking about rewriting it to make it a real Adapter like this:
There is not so much difference to the version above. (I'd probably extract the isSingle to something like to01String().) I have 1 class less since I don't need the ClientValues class anymore. But the Adapter class now has state. Perhaps this is better than my first approach? I am not sure.