Parlons d'abord du polymorphisme paramétrique pur et abordons le polymorphisme borné plus tard.
Que signifie le polymorphisme paramétrique? Eh bien, cela signifie qu'un type, ou plutôt un constructeur de type, est paramétré par un type. Étant donné que le type est transmis en tant que paramètre, vous ne pouvez pas savoir à l'avance ce qu'il pourrait être. Vous ne pouvez faire aucune hypothèse sur cette base. Maintenant, si vous ne savez pas ce que cela pourrait être, alors à quoi ça sert? Que pouvez-vous en faire?
Eh bien, vous pouvez le stocker et le récupérer, par exemple. C'est le cas que vous avez déjà mentionné: les collections. Afin de stocker un élément dans une liste ou un tableau, je n'ai besoin de rien savoir sur l'élément. La liste ou le tableau peut être complètement inconscient du type.
Mais qu'en est-il du Maybe
type? Si vous ne le connaissez pas, Maybe
c'est un type qui a peut-être une valeur et peut-être pas. Où l'utiliseriez-vous? Eh bien, par exemple, lorsque vous extrayez un élément d'un dictionnaire: le fait qu'un élément ne soit pas dans le dictionnaire n'est pas une situation exceptionnelle, donc vous ne devriez vraiment pas lever d'exception si l'élément n'est pas là. Au lieu de cela, vous renvoyez une instance d'un sous-type de Maybe<T>
, qui a exactement deux sous-types: None
et Some<T>
. int.Parse
est un autre candidat de quelque chose qui devrait vraiment retourner au Maybe<int>
lieu de lancer une exception ou la int.TryParse(out bla)
danse entière .
Maintenant, vous pourriez dire que Maybe
c'est un peu comme une liste qui ne peut avoir que zéro ou un élément. Et donc un peu une collection.
Et alors Task<T>
? C'est un type qui promet de renvoyer une valeur à un moment donné dans le futur, mais qui n'a pas nécessairement de valeur pour le moment.
Ou alors Func<T, …>
? Comment représenteriez-vous le concept d'une fonction d'un type à un autre si vous ne pouvez pas résumer les types?
Ou, plus généralement: considérant que l'abstraction et la réutilisation sont les deux opérations fondamentales de l'ingénierie logicielle, pourquoi ne voudriez- vous pas pouvoir abstraire sur des types?
Parlons maintenant du polymorphisme borné. Le polymorphisme borné est essentiellement le point de rencontre du polymorphisme paramétrique et du polymorphisme de sous-type: au lieu qu'un constructeur de type ne soit pas complètement conscient de son paramètre de type, vous pouvez lier (ou contraindre) le type à être un sous-type d'un type spécifié.
Revenons aux collections. Prenez une table de hachage. Nous avons dit plus haut qu'une liste n'a pas besoin de connaître quoi que ce soit sur ses éléments. Eh bien, une table de hachage le fait: elle doit savoir qu'elle peut les hacher. (Remarque: en C #, tous les objets sont hachables, tout comme tous les objets peuvent être comparés pour l'égalité. Ce n'est pas vrai pour tous les langages, cependant, et est parfois considéré comme une erreur de conception même en C #.)
Donc, vous voulez contraindre votre paramètre de type pour que le type de clé dans la table de hachage soit une instance de IHashable
:
class HashTable<K, V> where K : IHashable
{
Maybe<V> Get(K key);
bool Add(K key, V value);
}
Imaginez si vous aviez à la place ceci:
class HashTable
{
object Get(IHashable key);
bool Add(IHashable key, object value);
}
Que feriez-vous avec une value
sortie de là? Vous ne pouvez rien en faire, vous savez seulement que c'est un objet. Et si vous itérez dessus, tout ce que vous obtenez est une paire de quelque chose que vous savez est un IHashable
(qui ne vous aide pas beaucoup car il n'a qu'une propriété Hash
) et quelque chose que vous savez est un object
(qui vous aide encore moins).
Ou quelque chose basé sur votre exemple:
class Repository<T> where T : ISerializable
{
T Get(int id);
void Save(T obj);
void Delete(T obj);
}
L'élément doit être sérialisable car il va être stocké sur le disque. Mais que se passe-t-il si vous avez ceci à la place:
class Repository
{
ISerializable Get(int id);
void Save(ISerializable obj);
void Delete(ISerializable obj);
}
Avec le cas générique, si vous mettez un BankAccount
, vous obtenez un BankAccount
retour, avec des méthodes et des propriétés telles que Owner
, AccountNumber
, Balance
, Deposit
, Withdraw
, etc. Quelque chose que vous pouvez travailler avec. Maintenant, l'autre cas? Vous mettez dans un BankAccount
mais vous récupérer un Serializable
, qui vient d' une propriété: AsString
. Qu'allez-vous faire avec ça?
Il y a aussi quelques astuces que vous pouvez faire avec le polymorphisme borné:
La quantification délimitée par F est essentiellement l'endroit où la variable de type apparaît à nouveau dans la contrainte. Cela peut être utile dans certaines circonstances. Par exemple, comment écrivez-vous une ICloneable
interface? Comment écrivez-vous une méthode où le type de retour est le type de la classe d'implémentation? Dans une langue avec une fonctionnalité MyType , c'est simple:
interface ICloneable
{
public this Clone(); // syntax I invented for a MyType feature
}
Dans un langage avec polymorphisme borné, vous pouvez faire quelque chose comme ceci à la place:
interface ICloneable<T> where T : ICloneable<T>
{
public T Clone();
}
class Foo : ICloneable<Foo>
{
public Foo Clone()
{
// …
}
}
Notez que ce n'est pas aussi sûr que la version MyType, car rien n'empêche quelqu'un de simplement passer la "mauvaise" classe au constructeur de type:
class EvilBar : ICloneable<SomethingTotallyUnrelatedToBar>
{
public SomethingTotallyUnrelatedToBar Clone()
{
// …
}
}
Membres de type abstrait
Il s'avère que si vous avez des membres de type abstrait et un sous-typage, vous pouvez réellement vous passer complètement du polymorphisme paramétrique et toujours faire les mêmes choses. Scala se dirige dans cette direction, étant le premier langage majeur qui a commencé avec des génériques et essayant ensuite de les supprimer, ce qui est exactement l'inverse de Java et C # par exemple.
Fondamentalement, dans Scala, tout comme vous pouvez avoir des champs, des propriétés et des méthodes en tant que membres, vous pouvez également avoir des types. Et tout comme les champs, les propriétés et les méthodes peuvent être laissés abstraits pour être implémentés dans une sous-classe plus tard, les membres de type peuvent également être laissés abstraits. Revenons aux collections, un simple List
, qui ressemblerait à quelque chose comme ça, s'il était pris en charge en C #:
class List
{
T; // syntax I invented for an abstract type member
T Get(int index) { /* … */ }
void Add(T obj) { /* … */ }
}
class IntList : List
{
T = int;
}
// this is equivalent to saying `List<int>` with generics
interface IFoo<T> where T : IFoo<T>
aussi. c'est évidemment une application réelle. l'exemple est génial. mais pour une raison quelconque, je ne me sens pas satisfait. je veux plutôt me faire une idée quand c'est approprié et quand ça ne l'est pas. les réponses ici ont une certaine contribution à ce processus, mais je me sens toujours incomfy autour de tout cela. c'est étrange parce que les problèmes de langue ne me dérangent pas depuis si longtemps déjà.