Return to Answer

Every interface you offer to outside clients gives you restrictions. For example, if you have a method

    public double computeMean(double[] values) {
    ...
    }

You give a promise that you accept double[] arrays, but what if you deliverd the code to customers and suddenly realize that ArrayList<Double> would be better? And maybe you don´t know if there are clients who call your method, so you can not just change it to ArrayList.

If it is public and the values are already known to the class, you don´t need the parameters. This gives you the freedom to change from double[] to whatever you want, without changing your interface.

If it is a private method, you don´t need the parameters, they would be boilerplate code since you already know the values as you said.

So it depends on your clients if you should add the parameters.

Every interface you offer to outside clients gives you restrictions. For example, if you have a method

    public double computeMean(double[] values) {
    ...
    }

You give a promise that you accept double[] arrays, but what if you deliverd the code to customers and suddenly realize that ArrayList<Double> would be better? And maybe you don´t know if there are clients who call your method, so you can not just change it to ArrayList.

If it is public and the values are already known to the class, you don´t need the parameters. This gives you the freedom to change from double[] to whatever you want, without changing your interface.

If it is a private method, you don´t need the parameters, they would be boilerplate code since you already know the values as you said.

If you want a really generic function that does not depend on the class at all (which means there is no state to keep track of) you can make a static method that gets all information it needs from the parameters, if you don´t keep any state in your class at all you don´t even need an instance of this class. Like in Java Collections.sort(...).

So it depends on your clients if you should add the parameters.

Every interface you offer to outside clients gives you restrictions. For example, if you have a method

    public double computeMean(double[] values) {
    ...
    }

You give a promise that you accept double[] arrays, but what if you deliverd the code to customers and suddenly realize that ArrayList<Double> would be better? And maybe you don´t know if there are clients who call your method, so you can not just change it to ArrayList.

If you didn´t make this method public in the first place, there are no problems.

If it is public and the values are already known to the class, you don´t need the parameters and you can internally change to ArrayList<Double> without breaking anything.

If it is a private method, you don´t need the parameters, they would be boilerplate code since you already know the values as you said.

So it depends on your clients if you should add the parameters.

Every interface you offer to outside clients gives you restrictions. For example, if you have a method

    public double computeMean(double[] values) {
    ...
    }

You give a promise that you accept double[] arrays, but what if you deliverd the code to customers and suddenly realize that ArrayList<Double> would be better? And maybe you don´t know if there are clients who call your method, so you can not just change it to ArrayList.

If it is public and the values are already known to the class, you don´t need the parameters. This gives you the freedom to change from double[] to whatever you want, without changing your interface.

If it is a private method, you don´t need the parameters, they would be boilerplate code since you already know the values as you said.

So it depends on your clients if you should add the parameters.

Every interface you offer to outside clients gives you restrictions. For example, if you have a method

    public double computeMean(double[] values) {
    ...
    }

You give a promise that you accept double[] arrays, but what if you deliverd the code to customers and suddenly realize that ArrayList<Double> would be better? And maybe you don´t know if there are clients who call your method, so you can not just change it to ArrayList. If you didn´t make this method public in the first place there are no problems. If it is public but has no parameters, and the values are already known to the class, you can internally change to ArrayList<Double> without breaking anything. So it depends on your clients if you should add the parameters.

Every interface you offer to outside clients gives you restrictions. For example, if you have a method

    public double computeMean(double[] values) {
    ...
    }

You give a promise that you accept double[] arrays, but what if you deliverd the code to customers and suddenly realize that ArrayList<Double> would be better? And maybe you don´t know if there are clients who call your method, so you can not just change it to ArrayList. 

If you didn´t make this method public in the first place, there are no problems. 

If it is public and the values are already known to the class, you don´t need the parameters and you can internally change to ArrayList<Double> without breaking anything.

If it is a private method, you don´t need the parameters, they would be boilerplate code since you already know the values as you said. 

So it depends on your clients if you should add the parameters.