12
votes

Héritage de liste pour implémenter des collections une mauvaise idée?

I Une fois, j'ai lu un article par Imaar Spaanjars sur la construction de 3 applications de niveau. ( http: // imar. spaanjaars.com/416/building-layered-web-Applications-With-MicRosoft-aspnet-20-Part-1 ) qui a formé la base de mon codage pendant un moment maintenant.

Ainsi, je implique des collections comme il l'a fait, en héritant une liste code>. Donc, si j'ai une classe nommée employée, mettre en œuvre une collection, je disposerai également d'un employé de classe comme ci-dessous. P>

List<Employee> newEmployees = AllEmployees.FindAll(emp => emp.JoiningDate > DateTime.Now);


0 commentaires

4 Réponses :


19
votes

Je n'hériterais pas de Liste - il introduit des problèmes tels que ceux-ci et ne vous aide pas vraiment (car il n'y a pas de méthodes virtuelles à remplacer) . Je voudrais soit utiliser list (ou plus abstrait ilist ) ou pour introduire le polymorphisme collection a méthodes virtuelles.

comme une note; Rebout , vous pouvez également trouver les options LINQ (comme .where () ) des contreparties utiles; Plus particulièrement, ils travailleront pour tout iList (ou ienumerable ), pas seulement Liste et sous-classes.


2 commentaires

À droite, mais un petit doute. J'ai plusieurs projets comme DAL et BLL, les entités et PL. Les entités sont là où je définis les classes comme les employés, puis les utiliser dans d'autres projets. L'idée est que chaque projet peut être travaillé sur indépendante de l'autre. Existe-t-il une possibilité qu'un développeur puisse utiliser IList en BLL et un autre développeur peut utiliser la collection à DAL, qui peut causer des problèmes. Le point définit une implémentation en entités et laissez les autres l'utiliser partout où ils le souhaitent.


@SassyBoy - Depuis Collection Implements Ilist , ce n'est généralement pas un problème. En fin de compte, vous n'êtes pas vraiment définir une implémentation appropriée par sous-classement Liste , car cela ne fait rien pour permettre une logique spécifique à T.



11
votes

quel avantage obtenez-vous par sous-classement list ? Si cela n'ajoute rien alors c'est un code de code inutile. Si vous ne montrez pas des méthodes ou appliquez des contrats à travers un constructeur que vous n'avez pas montré ici, il pourrait s'agir d'une raison valable de la sous-classement.

En termes de résolution de votre problème de coulée, vous ne pouvez pas souscrire à une liste à un Employés comme Liste n'hérite pas de employés . Si vous devez renvoyer un employé avec vos critères, vous êtes préférable d'encapsuler l'appel et d'insérer les éléments de liste retournés dans votre propre objet. Cela ressemble à une perte de temps pour moi, sauf si j'ai dit ci-dessus, vous avez une bonne raison pour la sous-classe List .

Personnellement, j'essaierais d'utiliser ilist où toujours possible et ne crée pas de sous-classes à moins d'avoir une raison d'exister.


0 commentaires

4
votes

Je fermerais personnellement la liste en tant que membre d'un objet de conteneur et si nécessaire pour que Necesery fournisse obtenir un accessor à la liste elle-même. XXX

Je dois admettre que je l'ai fait pour me fournir cela méthodes telles que: xxx

sur la classe de base et: xxx

i (toujours) utilisez .net 2.0 donc je n'ai pas de Linq - Peut-être que c'est la raison de cela.


0 commentaires

4
votes

Une simple règle de base est de commencer par la composition (par exemple, envelopper les employés autour d'une collection générique) et non d'héritage. À partir de la conception basée sur l'héritage, vous peignez-vous dans un coin. La composition est plus flexible et modifiable.


0 commentaires