# 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<I,O>{
O get(I input);
}


with child classes being public class ServiceAProxy implements

 Provider<PropertyARequestForServiceA,PropertyA>{
PropertyA getPropertyA(PropertARequestForServiceA input){
return serviceA.getPropertyA(input.getParam1, input.getParam2);
}
}


and

public class ServiceBProxy implements Provider<PropertyARequest2,PropertyA>{
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.

• Some more context would be helpful. – slowy Sep 13 '17 at 12:08
• I have added some addition details, let me know if you wanted something that is not mentioned. – Vardaan Sharma Sep 13 '17 at 12:39