Passing some redundant parameters to an interface vs creating a new request object every time for the interface I am writing a proxy class, that will fetch a certain property (say propertyA) by calling an underlying service.

Currently we use Service A to get propertyA, but there is a chance that in the near future, we might migrate to service B to get propertyA instead.

Approach 1:
I wanted to make ServiceAProxy and ServiceBProxy both extend a common interface say PropertyAProxy that looks something like this

public interface PropertyAProxy{
    PropertyA getPropertyA(param1,param2, param3);
}


with the child classes as

public class ServiceAProxy implements PropertyAProxy{
    PropertyA getPropertyA(param1,param2,param3){
        return serviceA.getPropertyA(param1,param2); //param 3 is not needed for service A
    }
}


and

public class ServiceBProxy implements PropertyAProxy{
    PropertyA getPropertyA(param1,param2,param3){
        return serviceB.getPropertyA(param1,param2,param3);
    }
}


Approach 2:
or should I go for a really generic Provider interface

public interface Provider&lt;I,O&gt;{
    O get(I input);
}


with child classes being
public class ServiceAProxy implements 

 Provider&lt;PropertyARequestForServiceA,PropertyA&gt;{
            PropertyA getPropertyA(PropertARequestForServiceA input){
                return serviceA.getPropertyA(input.getParam1, input.getParam2);
            }
        }


and

public class ServiceBProxy implements Provider&lt;PropertyARequest2,PropertyA&gt;{
    get(param1,param2,param3){
        return serviceB.getPropertyA(input.getParam1, input.getParam2,input.getParam3);
    }
}


My concerns with approach 1 are:


I am passing param3 to ServiceAProxy even though its not needed.
With the visibility I CURRENTLY have, we wont need anything else besides param1, param2 and param3. But in the future there might be a ServiceC which needs param4 and not param 1.


My concerns with approach 2:


For every input object i will have to define a new pojo to act as a request object, and that seems a bit excessive to have so many request classes (especially since the code base im working on is already getting quite large)


Additional Context:
I will be using serviceA to get paramA for now, but there is a VERY high chance that some point in the future we will migrate to serviceB to get paramA.
To avoid pains in the future, I wanted to make the callers of the proxy to call an interface instead, so that I could switch the underlying proxy implementation without having to rewrite the calling logic.

Approach 1, is simpler to implement, but i may end up passing parameters that are never used.
Approach 2, is more generic, but involves me making request objects for each implementation, which I personally feel is overkill.

I have no STRONG inclination over either approach, and hence reaching out to the wider community.
Since what you want is a total transparency on how you access the propertyA then solution 1 seems better. Because with solution 2 you have to change the request object.

You should clearly identify your parameters. Some may be changing the output that is needed, other may be more related to the underlying service and can be "defaulted" into the dedicated proxy. At the end if you still have some unused parameters, this is acceptbale until the response is still correct.

It is not because the serviceB has a functionnality (param3) that you are obliged to use it. Your services should have a common behavior if you want to exchange them without any impacts.