EXTENSION DES LISTES GÉNÉRIQUES (DESIGN PATTERN "DECORATEUR")

Signaler
Messages postés
219
Date d'inscription
jeudi 6 juillet 2006
Statut
Membre
Dernière intervention
7 septembre 2009
-
Messages postés
305
Date d'inscription
lundi 7 janvier 2002
Statut
Membre
Dernière intervention
10 août 2011
-
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/44247-extension-des-listes-generiques-design-pattern-decorateur

Messages postés
305
Date d'inscription
lundi 7 janvier 2002
Statut
Membre
Dernière intervention
10 août 2011
4
très juste TheManu ;)
Messages postés
8
Date d'inscription
jeudi 26 juillet 2007
Statut
Membre
Dernière intervention
11 mai 2010

Sympa ta classe !
Par contre :
- Dans 'Clear()', pourquoi ne pas utiliser 'RemoveAt(0)' plutôt que 'Remove(this[0])' ?
De plus (et de toute façon), si un autre thread supprime entre le 'while' et le 'Remove' (ou le 'this[0]') un élément ET que celui-ci été le dernier t'es marron ! Je sais que c'est plus pour le tutorial mais je ne pense pas que tu puisses (pour simplifier l'écriture) te passer d'un 'lock' englobant la boucle d'effacement et le lancement d'évènements. Pour simplifier il faudrait (je pense) l'appel en boucle (et dans un 'lock') d'un "RemoveAtNonSafeThread(0)"...
- De même : l'énumération sur la liste (grâce à 'GetEnumerator') n'est pas "thread-safe" !
Messages postés
5
Date d'inscription
vendredi 4 juin 2004
Statut
Membre
Dernière intervention
23 novembre 2007

Sauf qu'ici il fait un lock(base) ce qui revient (dans le contexte d'une implémentation d'une IList<T>) à ce que tu conseilles MALKUTH mais le conseil est judicieux pour d'autre cas.
Messages postés
268
Date d'inscription
samedi 22 février 2003
Statut
Membre
Dernière intervention
24 avril 2013
2
Petite précision sur le lock, il est déconseillé de faire un
lock(this){ ... }

Car d'autre partie du programme pourais vouloir posé un vérou
sur l'objet pour des raison totalement différente que celle de
l'ajout d'un nouvel item dans la liste, pour ma part, je déclare
un un objet suplémentaire dans ma classe pour géré le lock :
private object modif_LOCK = new object();

On utilise ensuite :
lock(this.modif_LOCK) { ... }

On peut aussi noté que lock n'est pas une instruction du framework
à proprement parlé mais un artifice du compilateur C# qu'on peut
interprété comme ceci :
try
{
Sytem.Threading.Monitor.Enter(this.modif_LOCK);
...
}
finally
{
Sytem.Threading.Monitor.Exit(this.modif_LOCK);
}

Il est possible de dans certain cas d'utilisé d'autre classe que
Sytem.Threading.Monitor pour géré les vérroux comme par example :
ReaderWriterLock
qui permet de diférencié les opérations de lectures(qui ne se lock pas entre elles) des opérations d'écriture (qui sont exclusive).
Afficher les 15 commentaires