I have an instance method that uses instance fields in its work. I can leave the method without that parameters as they're available to me, or I can add them to the parameter list, thus making my method more "generic" and not reliable on the class. On the other hand, additional parameters will be in parameters list. Which approach is preferable and why?

Edit: at the moment I don't know if my method will be public or private.

Edit2: clarification: both method and fields are instance level.

  • Is your method public? Oct 1, 2012 at 10:01
  • @john: I think it depends. Sometimes you had better leave things as simple as they do, unless you have strong indications that the generic design is needed in near future. Oct 3, 2012 at 2:16
  • Not knowing if your method will end up public or private is actually a design alarm that something is wrong.
    – Songo
    Oct 7, 2012 at 11:58

6 Answers 6


IMO, "making my method more "generic" and not reliable on the class" is not a good goal, since it promotes classes with low cohesion.

If your method is generic enough to serve for other classes, too, then take it out of the class and move it to a "function library" class. (But beware of the functional decomposition antipattern).

  • 1
    +1 the cohesion. Removed my answer, yours is shorter, better and exactly what I was looking for
    – Jalayn
    Oct 1, 2012 at 12:46

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.


Well, unless you need to interface with the outer world, it is not useful to add parameters, neither if in view of needing it later.

If you should realize at a certain time you need to provide this method with parameters, then you may overload this method at that moment, accepting parameters in the new signature and manage it out that way.

Generally speaking I tend to consider a good design approach leaving eventual 2nd generation changes out of scope, if my specification is well-defined.

It is better to keep design as minimal as possible, but open to later eventual changes.

This means that, given a situation like yours, it is not useful to trust program evolution immediately; instead stick to actual specifications, designing with an eye to what it is reasonable to be expected.


Short anwer: If the instance method has access to the instances variables then there is no need to pass those same values as parameters.

If you want to create a class (static) methods, then such a method will no have access to any state, so you have to pass the values as parameters.


Think of it this way. If the instance variables are more related to the class as a whole, leave them in the class. If they are not related to the class but much more to a single method, make them parameters.

If you think this way, you will have a higher cohesion also, which one of the basic concepts of OO.


Whether the input to the method should be in instance fields or in parameters depends on what the method does. It depends on the method’s semantics, the method’s relationship to the class and its semantics, and the fields’ purpose within the class. You didn’t specify any of these, so the answer could be anything.

In general, if it makes at all sense for the method do all its work from parameters instead of instance fields, then my first instinct would be to wonder why the method is even in that class. Perhaps it should be a static utility method in some static helper class.

Differently put, if you think there is no question that the method clearly should be an instance method in that class, then it should seem equally unequivocal for it to use the class’s instance fields — it should seem impossible to do it any other way. Since you’re pulling that into question, you should pull the premise into question.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.