Règles sur le caractère concret des types de paramètres de méthode, des types de retour et des types de propriété

Il y a quelque temps, j'ai lu une sorte de "règle générale" sur le caractère concret des types de paramètres de méthode, des types de retour et des types de propriété, mais je ne m'en souviens tout simplement pas.

Cela a dit quelque chose à propos de garder vos types de retour aussi concrets que possible et vos types de paramètres aussi abstraits que possible ... ou vice versa.

Je ne sais pas si c'était en fait un bon ou un mauvais conseil, donc si vous avez vos propres réflexions à ce sujet, veuillez laisser un commentaire.

À votre santé.

Ne demandez pas plus, promettez rien de moins.

La phrase vient des idées «Design by Contract» lancées par Bertrand Meyer.

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

Voir également le "principe de substitution de Liskov"

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

Avoir des entrées abstraites et des sorties concrètes rend votre fonction plus générale. Cela signifie qu'il peut être utilisé de plusieurs manières. D'un autre côté, cela impose des contraintes plus fortes à votre méthode, limitant la façon dont les futures implémentations de celle-ci pourraient fonctionner. C'est donc un compromis entre différents objectifs.

Il se pourrait que vous ayez entendu une extrapolation de la loi de Postel : "Soyez conservateur dans ce que vous envoyez, libéral dans ce que vous acceptez."

Il s'agit principalement de maximiser la réutilisabilité du code. Il est facile de trouver des cas pour montrer pourquoi cela aide. Prenons l'exemple de Java Iterable<T>. Si la seule chose que votre méthode fait est de parcourir tous les Ts, avoir un Iterable<T>comme type de paramètre vous permet d'utiliser cette méthode avec plus de 60 classes intégrées, sans parler des classes personnalisées qui implémentent l'interface. Si vous le limitez à, disons, Vector<T>tout code qui appelle votre méthode devra être converti en Vector<T>premier.

D'un autre côté, le retour d' un à Iterable<T>partir d'une méthode limite la quantité de code qui peut utiliser votre valeur de retour à ceux qui prennent un Iterable<T>paramètre. Si vous retournez un type très concret, comme Vector<T>, votre valeur de retour peut être passé dans une méthode qui prend un Serializable, Cloneable, Iterable<T>, Collection<T>, List<T>, RandomAccess, Vector<T>, AbstractList<T>, ou AbstractCollection<T>, et cela fonctionnera comme prévu.