Há algum tempo, li uma espécie de "regra de ouro" sobre a concretude dos tipos de parâmetros de métodos, tipos de retorno e tipos de propriedades, mas simplesmente não me lembro.
Dizia algo sobre manter os tipos de retorno o mais concreto possível e os tipos de parâmetro o mais abstratos possíveis ... ou vice-versa.
Não sei se foi realmente um conselho bom ou ruim; por isso, se você tem seus próprios pensamentos, por favor, deixe um comentário.
Felicidades.
Respostas:
Não exija mais, não prometa menos.
A frase vem das idéias "Design by Contract", pioneiras em Bertrand Meyer.
http://wiki3.cosc.canterbury.ac.nz/index.php/Design_by_contract
Veja também o "princípio de substituição de Liskov"
/programming/56860/what-is-the-liskov-substitution-principle
Ter entradas abstratas e saídas concretas torna sua função mais geral. Isso significa que pode ser usado de várias maneiras. Por outro lado, impõe restrições mais fortes ao seu método, limitando como as implementações futuras do mesmo podem funcionar. Portanto, é uma troca entre objetivos diferentes.
Pode ser que você tenha ouvido uma extrapolação da lei de Postel : "Seja conservador no que envia, liberal no que aceita".
Principalmente, trata-se de maximizar a reutilização do código. É fácil criar casos para demonstrar por que ajuda. Considere o Java Iterable<T>como um exemplo. Se a única coisa que seu método faz é iterar todos os Ts, ter um Iterable<T>tipo de parâmetro permite que você use esse método com mais de 60 classes internas, sem mencionar as classes personalizadas que implementam a interface. Se você o limitou, digamos, a Vector<T>qualquer código que chame seu método, ele deverá ser convertido em um Vector<T>primeiro.
Por outro lado, retornar um Iterable<T>de um método limita a quantidade de código que pode usar seu valor de retorno àqueles que usam um Iterable<T>parâmetro. Se você retornar um tipo muito concreto, como Vector<T>, então o seu valor de retorno pode ser transmitida em qualquer método que leva um Serializable, Cloneable, Iterable<T>, Collection<T>, List<T>, RandomAccess, Vector<T>, AbstractList<T>, ou AbstractCollection<T>, e irá funcionar como esperado.