7
votes

Pourquoi les méthodes d'extension dans les bibliothèques de classe C #

J'ai parcouru certains Documentations MSDN . J'ai trouvé des méthodes d'extension également documentées là-bas.

Je n'ai pas compris, pourquoi ces bibliothèques de classe de base ont des méthodes d'extension? Quand ils auraient pu être ajoutés à cette bibliothèque de classe elle-même?

Quel est l'avantage? différence?

c# class-library extension-methods

0 commentaires

4 Réponses :

1
votes

Les méthodes d'extension comme nom suggère étend la fonctionnalité ou la convivialité du type cible.

Ces méthodes peuvent être ajoutées ultérieurement (que le temps de création de type) après le type a déjà été publié.
Ils peuvent être écrits par différents groupes de personnes
Les méthodes d'extension peuvent cibler des interfaces. (Une alternative aurait été d'avoir un type de base commun à ces procédés ou de les ré-mise en oeuvre dans chaque type)
Différentes personnes peuvent prolonger le même type différemment selon leurs besoins.
L'utilisation correcte des méthodes d'extension peut éliminer l'encombrement orthogonal de la définition / mise en oeuvre de type réelle (au lieu de la mise au point de la fonctionnalité de base du type dans la définition de type).
Prenez l'exemple de Linq - en fournissant des méthodes d'extension à iEnumerable , il pourrait cibler un grand nombre de types déjà publiés (et un grand nombre de types pouvant écrire à l'avenir); Il a une préoccupation orthogonale séparée, telle que l'interrogation du type du type réel.



                                                                    
                                    
                                    
                                        6 commentaires
                                        
                                                                                            
                                                    L'article 3 sur votre liste est complètement faux. Il défend complètement la mécanique des méthodes d'extension décrites dans votre "alternative". De plus, qu'entendez-vous par «interrogant le type du type actuel»?                                                
                                                
                                                                                            
                                                    @ A.R., Vous devez peut-être expliquer un peu ce qui est  faux  in # 3. Un bon exemple pour # 3 est  ienumerable   - si l'interface n'a pas pu être cible par des méthodes d'extension, alors un peu de corps devrait écrire la mise en œuvre pour toutes ces méthodes de type spécifique (ou leur type de base commun) .                                                

                                                
                                                                                            
                                                    @Ar, en outre, j'avais utilisé le terme "préoccupation orthogonale telle que l'interrogation du type du type" dans le contexte de  ienumerable  - cela signifie simplement que différentes collections telles que le dictionnaire, la liste, la file d'attente, Set, Stack, etc. ne doit pas nécessairement mettre en œuvre diverses méthodes de requête (joindre, compter, premier, dernier, etc.). Cette logique n'est vraiment pas la principale préoccupation de ces classes.                                                

                                                
                                                                                            
                                                    L'alternative réelle consiste à écrire une méthode statique qui prend une instance «ienumeralbe » comme argument. C'est exactement ce que font les méthodes d'extension lorsqu'elles sont compilées. Suggérant que certaines "classe de base" devraient "réapprouiller" quels montants à une fonction d'assistance est à la fois absurde et dangereusement trompeur. Prenez la méthode de l'extension 'Max' par exemple et utilisez-la dans votre "alternative" suggérée. À quel moment dois-je exactement le ré-mise en œuvre?                                                
                                                
                                                                                            
                                                    Votre dernier point sur Linq et explication pour cela n'a aucun sens. Vous suggérez que des méthodes de vulgarisation «fournissent la mise en œuvre» sur ces types de collecte et que ce n'est pas quelles méthodes d'extension font.                                                
                                                
                                                                                            
                                                    @ A.R., Les méthodes d'assistance statique auraient pu être écrites depuis .net 1.0. L'idée même des méthodes de vulgarisation est qu'elles semblent faire partie de (membre de) type! Donc, pour  max  une partie de l'interface  iEnumerable  , chaque implémentation d'interface devrait l'appliquer.

1 votes Les méthodes d'extension documentées sont définies sur ienumerable , quel ObjectSet implémente. Ils sont documentés pour que vous sachiez que vous pouvez les utiliser. comme méthodes d'extension, ils finissent par extension tout type implémentant cette interface, gratuitement. 0 commentaires 3 votes Remarque, que de nombreuses ces méthodes fonctionnent sur des interfaces, qui constitue une excuse parfaitement légitime d'utiliser des méthodes d'extension, même pour Microsoft, car les interfaces elles-mêmes ne peuvent avoir aucune mise en œuvre de méthodes. 0 commentaires 0 votes Je pense que c'est la plus probablement un "problème de marketing". La façon de conseiller BCL consommateur (US) à utiliser des méthodes d'extension, où nous en avons besoin. du point de vue de la convivialité, il y a aucune bonté , imo, de les intégrer dans BCL 0 commentaires

Articles qui pourrait vous intéresser : Calculer la différence dans l'échelle d'évaluation alphabétique Ignorer la propriété de l'interface utilisateur Swagger Comment détruire les éléments dynamiques du panneau dans le script Unity C # Entity Framework Core 3.1 avec NetTopologySuite.Geometries.Point: SqlException: la valeur fournie n'est pas une instance valide de la géographie du type de données