Reglas sobre la concreción de los tipos de parámetros de métodos, tipos de retorno y tipos de propiedades

Hace algún tiempo leí una especie de "regla de oro" sobre la concreción de los tipos de parámetros de métodos, tipos de retorno y tipos de propiedades, pero simplemente no lo recuerdo.

Decía algo sobre mantener sus tipos de retorno lo más concretos posible y sus tipos de parámetros lo más abstractos posible ... o viceversa.

No sé si fue realmente un buen o mal consejo, así que si tienes tus propios pensamientos al respecto, deja un comentario.

Salud.

No requiera más, no prometa menos.

La frase surge de las ideas de "Diseño por contrato" iniciadas por Bertrand Meyer.

http://wiki3.cosc.canterbury.ac.nz/index.php/Design_by_contract

Ver también el "principio de sustitución de Liskov"

/programming/56860/what-is-the-liskov-substitution-principle

Tener entradas abstractas y salidas concretas hace que su función sea más general. Esto significa que se puede usar de más maneras. Por otro lado, impone restricciones más fuertes de su método, limitando cómo podrían funcionar las implementaciones futuras del mismo. Por lo tanto, es una compensación entre diferentes objetivos.

Podría escucharse una extrapolación de la ley de Postel : "Sea conservador en lo que envía, liberal en lo que acepta".

Principalmente se trata de maximizar la reutilización del código. Es fácil encontrar casos para demostrar por qué ayuda. Considere Java Iterable<T>como ejemplo. Si lo único que hace su método es iterar a través de todos los Ts, tener un Iterable<T>tipo de parámetro como le permite usar ese método con más de 60 clases incorporadas, sin mencionar las clases personalizadas que implementan la interfaz. Si lo limita a, digamos, Vector<T>entonces cualquier código que llame a su método tendría que convertirse a un Vector<T>primero.

Por otro lado, devolver un Iterable<T>método a partir de un método limita la cantidad de código que puede usar su valor de retorno a aquellos que toman un Iterable<T>parámetro. Si devuelve un tipo muy concreto, como Vector<T>, a continuación, su valor de retorno se puede pasar a cualquier método que toma una Serializable, Cloneable, Iterable<T>, Collection<T>, List<T>, RandomAccess, Vector<T>, AbstractList<T>, o AbstractCollection<T>, y funcionará como se espera.