Some time ago I read a kind of "rule of thumb" about the concreteness of method parameter types, return types and property types, but I just do not remember it.

It said something about keep your return types as concrete as possible and your parameter types as abstract as possible... or vice versa.

I don't know if it was actually a good or bad advice, so if you have your own thoughts about it, please let a comment.


3 Answers 3


Require no more, promise no less.

The phrase comes out of "Design by Contract" ideas pioneered by Bertrand Meyer.


Also see the "Liskov substitution principle"



Having abstract inputs and concrete outputs makes your function more general. This means it can be used in more ways. On the other hand it puts stronger constraints of your method, limiting how future implementations of it might work. So it's a trade-off between different goals.


It could be you heard an extrapolation of Postel's law: "Be conservative in what you send, liberal in what you accept."

Mostly it's about maximizing code reusability. It's easy to come up with cases to demonstrate why it helps. Consider Java's Iterable<T> as an example. If the only thing your method does is iterate through all the Ts, having an Iterable<T> as your parameter type allows you to use that method with over 60 built-in classes, not to mention any custom classes that implement the interface. If you limited it to, say, Vector<T>, then any code that calls your method would have to convert to a Vector<T> first.

On the other hand, returning an Iterable<T> from a method limits the amount of code that can use your return value to those that take an Iterable<T> parameter. If you return a very concrete type, like Vector<T>, then your return value can be passed into any method that takes a Serializable, Cloneable, Iterable<T>, Collection<T>, List<T>, RandomAccess, Vector<T>, AbstractList<T>, or AbstractCollection<T>, and it will work as expected.

  • Postel's law is pretty high on my list of "biggest software engineering mistakes". Commented Feb 27, 2013 at 20:30

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.