Je fais du développement .NET depuis longtemps, et j’ai récemment critiqué le livre « C# Advanced Programming ». J’ai constaté que de nombreux problèmes que je semblais comprendre mais que je ne comprenais pas peuvent en réalité être étudiés et compris lentement.
Donc, je prévois de commencer à écrire un article de blog sur la « C# Advanced Programming Series ». Il s’inspirera du concept du livre « C# Advanced Programming », et fera également référence aux articles de blog d’autres experts, j’espère que vous comprenez. S’il y a un problème, merci de corriger cela.
(Aussi : cet article de blog n’expliquera pas les bases des définitions et de la grammaire.) ）
Parlons de la mise en service.
Delegate est largement utilisé dans .NET. Des expressions lambda, des événements, des méthodes d’anonymat, etc. seront impliqués (restez à l’écoute pour les prochains articles de blog).
Alors, qu’est-ce que l’entrustment ?
En termes simples, les délégués ne diffèrent pas des méthodes de spécification, sauf qu’ils doivent spécifier le mot-clé délégué et n’ont pas d’entité de méthode. Vous pouvez le considérer comme un symbole temporaire, par exemple, lorsque vous écrivez du code sans savoir à quoi vous allez faire face. Il suffit de savoir quel est le type de paramètre et le type de sortie que vous allez introduire et de les définir. C’est la méthode indiquée dans le livre selon laquelle la signature doit signifier la même chose.
Définissons une délégation de base :
Résultats d’exécution :
Voyez-vous l’endroit pratique ci-dessus à qui confier ? À savoirUn délégué peut exécuter n’importe quelle méthode avec le même type de paramètre d’ingestion et le même type de retour, ou même une file d’attente de méthode avec la même signature.
Donc, nos signatures de méthode (c’est-à-dire les paramètres d’importation et de sortie) doivent-elles vraiment être exactement les mêmes que celles du délégué ? Réponse : Non, nous ne pouvons pas ignorer la covariance et la variation inverse.
Introduisons brièvement les connaissances sur le covariant et l’onduleur.
« Covariance » signifie pouvoir utiliser un type plus dérivé que le type dérivé initialement spécifié.
« Onduleur » fait référence à la capacité d’utiliser un type avec un degré de dérivation plus moindre.
Ensuite, notre commission est également soumise à la covariance et à l’inverse.
Cela signifie que si un délégué est défini, non seulement la même méthode de signature peut attribuer une valeur à la variable déléguée.
Si la table des paramètres d’une méthode correspond à la déclaration de délégué, mais retourne une classe dérivée de (la déclaration de délégué retourne le type), alors la méthode peut également être assignée à cette variable déléguée.
Si le type de retour d’une méthode correspond à la déclaration du délégué, mais que l’argument est la classe ancêtre du type de paramètre de déclaration du délégué, alors la méthode peut également être assignée à la variable déléguée.
Si les paramètres et le type de retour d’une méthode correspondent aux hypothèses des deux lignes ci-dessus, alors la méthode peut également être assignée à la variable déléguée.
Voici un exemple simple de covariant vs. onduleur :
Covariance :
Onduleur :
|
Publié sur 19/01/2017 15:18:00
|
|
|
|
