OOP -- defining an interface method with a certain intent

I'm developing a computational framework to run some calculations on the given data-sets. It runs the data-set across a few algorithms, say Calculator-s, and picks the best outcome.

Each Calculator (there are 3 now) runs on “basic-input” and “specific-input”. “Basic-input” here is the same for all Calculator-s: the data-set in a certain form and a set of tuning params to tell the client preferences. In addition, each Calculator runs on “specific-input”: 2 or 3 parameters to tell the assumed restrictions to it. (The Calculator-s are solving an NP-hard problem-- the “specific-input” are tuning each Calculator on these restrictions and vary in type & number by the Calculator.)

A Calculator in the system is a type that implements a Calculator interface – that's how the system recognizes them. The Calculator interface has a runCalculator() method – the handle to invoke it.

Currently, the signature of runCalculator() is as follows:

Result runCalculator(Object...settings) ; 

Result here is a type that defines the ultimate result they all produce.

In the framework, I'm currently passing the “basic-input” params to constructor of each Calculator, and “specific-input” params to runCalculator() of each of them. So – they all are instantiated on the same set of arguments, then run on the specific ones they each take.

My colleague argues that

Object...settings 

in the definition of runCalculator() in the interface is too vague – it should be precise, define and take the “basic-input” for one, then take the rest of it as precisely as possible.

My counter-argument is: runCalculator() in the interface is a handle – telling the client the method to invoke the Calculator to deliver the result. It can not be specific with all the params, cause the “specific-input” are different for each Calculator implementing it. I can change it to also take the “basic-input” -- to be something like:

Result runCalculator(DataSet dataSet, Integer theCode, Object...settings) ; 

and leave each constructor bare. This would instantiate each Calculator with nothing on, then leave all the work to runCalculator(). The constructors now are setting it up for the basics before runCalculator() gets in with the calculations.

We're running Java 7. If it were Java 8, i could make runCalculator() a static method, then take from there – runCalculator() would invoke the constructor, then the real-deal and this would tidy it up to both our “pleasure”.

I'm looking for opinions on this – how right/wrong are me and my colleague each?

Note – 1: This may look like a matter of Strategy Pattern, but it isn't. The client still has to pass the “specific-input” to a Calculator – the Q is how-well-defined to pass them.

Note-2: May also look like the Builder Pattern but isn't for the same reason.

TIA.