Est-il correct d'utiliser l'héritage au lieu d'alias de nom en c #?

Question

En d'autres termes, est-il correct d'utiliser:

public class CustomerList : System.Collections.Generic.List<Customer>
{
    /// supposed to be empty
}

au lieu de:

using CustomerList = System.Collections.Generic.List<Customer>

Je préférerais utiliser la première approche car je ne définissais qu'une seule fois CustomerList. Chaque fois que j'avais besoin d'une liste de clients, j'utilisais toujours le même type. D'autre part, utiliser l'approche du pseudonyme me contraint non seulement à le redéfinir partout, mais également à un alias différent chaque fois que quelqu'un voudrait l'utiliser (pensez à une grande équipe), ce qui entraînerait le code. être moins lisible.

Veuillez noter que dans ce cas, l'intention ne serait jamais d'étendre la classe, mais simplement de créer un alias.

Answer 1

Ne le fais pas. Quand les gens lisent:

List<Customer> 

ils le comprennent immédiatement. Quand ils lisent:

CustomerList

ils doivent déterminer ce qu'est une CustomerList, ce qui rend votre code plus difficile à lire. Sauf si vous êtes le seul à travailler sur votre base de code, écrire du code lisible est une bonne idée.

Answer 2

Eh bien, à moins d’ajouter des fonctionnalités à la classe de base, il n’est pas utile de créer un objet wrapper. J'irais avec le numéro deux si vous en avez vraiment besoin, mais pourquoi ne pas simplement créer une variable?

List<Customer> customerList = new List<Customer>();

Answer 3

Je serais d'accord avec ne pas utiliser un alias de cette manière. Aucun membre de votre équipe ne devrait utiliser des alias de la manière présentée. ce n'est pas la raison pour laquelle l'aliasing a été fourni. De plus, du point de vue du fonctionnement des génériques, il n’existe qu’une seule classe List, quel que soit le nombre d'emplacements où vous l'utilisez.

En plus de simplement déclarer et utiliser List<Customer>, vous voudrez éventuellement passer cette liste à autre chose. Évitez de passer le concret IList<Customer> et utilisez plutôt un ICollection<Customer> ou <=>, car cela rendra ces méthodes plus résilientes et plus faciles à programmer.

Un jour dans l’avenir, si vous avez réellement besoin d’une classe de collection CustomerList, vous pouvez y appliquer <=> ou <=> et continuer à la transmettre à ces méthodes sans que celles-ci ne soient modifiées ou même mieux connues.

Answer 4

En fait, vous ne devriez pas utiliser non plus. L’approche conforme aux directives de conception du cadre consiste à utiliser ou hériter de System.Collections.ObjectModel.Collection < T > dans les API publiques (La liste < T > ne doit être utilisée que pour une implémentation interne).

Mais en ce qui concerne le problème spécifique de la dénomination, il semble être recommandé d'utiliser le nom de type générique directement sans pseudonyme, sauf si vous devez ajouter des fonctionnalités à la collection:

  

Renvoyez la collection < T > de l'objet   modèles pour fournir plaine standard   API de collection vanille.

     

Renvoyez une sous-classe de la collection < T >   à partir de modèles d'objet pour fournir   API de collecte de haut niveau.

Answer 5

L’utilisation de l’héritage pour aliasing / typedefing pose le problème de vous demander de redéfinir les constructeurs pertinents.

Puisqu'il deviendra rapidement déraisonnable de le faire partout, il est probablement préférable de l'éviter pour des raisons de cohérence.

Answer 6

C’est l’une de ces questions "Cela dépend".

Si vous avez besoin d'une nouvelle classe qui se comporte comme une liste de clients en plus de vos autres besoins, alors l'héritage est la solution.

Si vous souhaitez simplement utiliser une liste de clients, utilisez la variable.

Answer 7

Si vous essayez simplement d’économiser sur la saisie, utilisez ce dernier. Vous ne rencontrerez pas d'étranges problèmes d'héritage de cette manière.

Si vous souhaitez réellement exposer un type de collection distinct sur le plan logique, utilisez l'ancien - vous pouvez y revenir et y ajouter des éléments.

Personnellement, je voudrais simplement utiliser List<Customer> et l’appeler un jour.

Answer 8

Je suis essentiellement d'accord avec Ed. Si vous n'avez pas réellement besoin d'étendre les fonctionnalités de la construction générique List, utilisez simplement une liste générique:

List<Customer> customerList = new List<Customer>();

Si vous avez besoin d'étendre la fonctionnalité, vous envisagez généralement l'héritage.

La troisième possibilité est celle où vous avez besoin de fonctionnalités considérablement modifiées à partir de la structure de liste générique, auquel cas vous pouvez simplement hériter de IEnumerable. Cela rend la classe utilisable dans les opérations énumérables (telles que & "; Foreach &";) Mais vous permet de définir complètement tout le comportement de la classe.

Answer 9

Les économies d’un programmeur sur la dactylographie pourraient très bien être le cauchemar de maintenance du prochain programmeur. Je dirais simplement de taper le générique correctement, comme beaucoup l'ont dit ici. C'est plus propre et une description plus précise de l'intention de votre code, et cela aidera le programmeur de maintenance. (Qui pourrait être vous, six mois et quatre nouveaux projets sur la route!)