Discussion :

[touftouf57]

Bonjour à tous,

Je suis en train de me demander, s'il est possible d'empêcher l'utilisation des méthodes de List (Add, Clear,...) sur un getter de List. En fait, je veux obliger le développeur qui reprendra ma classe de faire n'importe quoi, et l'obliger à utiliser les méthodes (Add, Clear,..) que ma classe expose.

Cela existe en C++, avec l'utilisation du mot clé "const", mais je n'ai plus la syntaxe exacte.

C'est une question qui intéresse toute l'équipe.

Merci, du coup de main

[hegros]

Il nous manque des informations. Quelle est ta classe que tu exposes ? C'est une classe qui hérite de List ??? Un morceau de code serait le bienvenue..

[touftouf57]

Oupss, j'ai oublié de préciser.
Ma classe possède une donnée membre LaList.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class MaClasse {
 
private List<AutreClasse> _laList= null;
.....
 
public void Add(AutreClasse autre){
     this._laList.add(autre);
     FaitAutreTraitement();
}
 
public List<AutreClasse> LaList{
      get{
           return _laList;
      }
}

Moi, je voudrais empêcher l'utilisateur de la classe de faire ce genre de code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

maClasse.LaList.Add(new AutreClasse(....));

Pour le forcer à utiliser:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

maClasse.Add(new AutreClasse(....));

Une idée?

[kheironn]

tu fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
public List<AutreClasse> LaList
{
      get
      {
           return _laList.AsReadOnly();
      }
}

la solution était dans les membres d'une liste sur msdn

[touftouf57]

Merci,

Je vais voir ce que cela donne. Nous on cherchait plutôt des mots clefs, au lieu de regarder les méthodes disponibles des collections.

Merci beaucoup.


Je viens de tester. Il y a un problème, que j'ai corrigé
Il faut modifier le type de retour de la méthode. Le retour sera IList<AutreClasse> au lieu de List<AutreClasse>

Encore merci

[kheironn]

Il faut toujours regarder les membres de la classe...
On y trouve plein de choses qu'on ne soupçonnait pas... il m'est arrivé de coder une méthode et de me rendre compte après coup qu'un objet m'offrait le service en question ! Maintenant, j'examine les membres !

en ce qui concerne ton cas, je faisais une méthode qui renvoyait une nouvele instance de List<T>, l'utilisateur la manipulait, mais celà ne changeait pas la liste originale... puis j'ai trouvé cette méthode et Hop !

[Bluedeep]

Le retour sera IList<AutreClasse> au lieu de List<AutreClasse>

Encore merci

En effet, AsReadOnly retourne en réalité une instance de ReadOnlyCollection<T> , qui implémente IList<T>

[Bluedeep]

Merci,

Je vais voir ce que cela donne. Nous on cherchait plutôt des mots clefs,

Le nombre de mot clef en C# est assez limité. (Presque) tout se passe avec le framework.

[sisqo60]

Bonjour,

Pourquoi empêcher d'utiliser des méthodes simples alors que tu peux utiliser une ObservableCollection ou créer une Classe "TaListe" qui implémente l'interface INotifyCollectionChanged ou INotifyCollectionChanging ou même les deux selon le cas...
Tu pourras ainsi savoir quand un élément est ajouté, modifié ou même supprimé et faire tes traitements (abonnements/désabonnements).

[Bluedeep]

Bonjour,

Pourquoi empêcher d'utiliser des méthodes simples alors que tu peux utiliser une ObservableCollection

T'as déjà fait des mesures de perf sur l'ObservableCollection ? Visiblement non; moi je l'ai fait, et c'est ... comment dire .... gratiné.

Dans la mesure où il veut exposer une liste non susceptible d'être modifiée (souvent le cas quand on expose cela depuis une classe, où seule la classe créé et modifie la liste - le framework est plein d'exemples internes) pourquoi diantre irait il implémenter une plomberie inutile autant que bizarre alors que le wrapper (car ce n'est qu'un wrapper, il n'y a pas de re-création de la liste) ReadOnlyCollection est là précisément pour cela ?

[sisqo60]

En terme de perf, OK.
Là on cherche un solution simple pour résoudre son problème, maintenant en fonction du traitement à réaliser, ça peut être plus long certes, mais quelques millisecondes c'est pas visible par la majorité des utilisateurs. Le sujet c'est pas un débat sur les perfs de l'ObservableCollection!

[Bluedeep]

En terme de perf, OK.
Là on cherche un solution simple pour résoudre son problème, maintenant en fonction du traitement à réaliser, ça peut être plus long certes, mais quelques millisecondes c'est pas visible par la majorité des utilisateurs. Le sujet c'est pas un débat sur les perfs de l'ObservableCollection!

Non,le sujet n'est pas les perfs de l'ObservableCollection.
En revanche, dire "quelques millisecondes c'est pas visible par la majorité des utilisateurs" est absurde car on a pas le contexte d'utilisation : rien ne dit qu'il s'agit d'une application front ! alors si c'est une appli serveur, quelques ms x 1000 ou plus, ce n'est plus du tout négligeable.

De plus, ici il demande un moyen pour exposer une collection non modifiable : quand on fait ce type de demande, en général c'est par ce qu'on fournit une bibliothèque tiers (au sens large) et qu'on ne veut pas que le client (au sens large encore) soit en mesure de modifier la liste exposée.

Or, dans ce cas, conseiller un système de plomberie pour auditer les abonnements à la collection me semble absurde, sans même parler de la dégradation énorme de perf(de mémoire - j'ai fait ces tests il y a plus de 4ans au moment de la sortie du Fx 3.0 - le ratio se chiffrait en ordre de grandeur et pas en "coeff" !), d'autant que ce que tu propose impose une modification beaucoup plus importante du code sans bénéfice a priori.

Personnellement, un dev me "pisse" plus de code que je n'aurais pensé initialement etr m'explique que ça gagne en perf. (dans la mesure du raisonnable) je dis OK, si il m'explique qu'il en met plus pour PERDRE en perf. sans raison fonctionnelle valable, il va revoir dare-dare sa copie.

Ergo, je maintiens que ta réponse est fumeuse.

[touftouf57]

Bien, je vois que ce post à lever pas mal de réaction.
Et je recherche tout de même de la perf, parce que l'appli fait pas mal d'accès en base de données, via ODBC. Déjà là, niveau perf c'est pourri. Ensuite la conception des requêtes est galère. Je parle bien conception de requête, parce que ODBC n'accepte pas les sous-requetes, et ce que l'on ferait en une requete en SQL (Oracle, mySQL,....) on doit le faire en 2 voir 3. Donc 2 * pourri + code galère à mettre en place + performances déplorables = Application à revoir complètement. Déjà que c'est une nouvelle version, d'une vieille appli, qui avait comme principales critiques:

• Ergonomie foireuse
• Lente
• Compliquée

Donc il ne faudrait pas la rendre pire qu'elle ne l'était à l'origine.
J'ai eut la réponse que j'attendais: Comment faire l'équivalent en C# de List<AutreClasse> laListe () const en C++?

En tout cas merci à tous pour m'avoir aider, et plus particulièrement kheironn qui a été le premier à me donner la soluce.

[Nathanael Marchand]

Après, ca dépend aussi des membres que tu utilises mais tu pourrais ne renvoyer qu'un Enumerable<T>

[Bluedeep]

Après, ca dépend aussi des membres que tu utilises mais tu pourrais ne renvoyer qu'un Enumerable<T>

L'inconvénient,en plus de l'absence d'indexer, est que tu ne peux pas tester directement la présence d’éléments, tu es obligé de passer par une méthode d'extension Linq qui va énumérer le tout.

[Nathanael Marchand]

L'inconvénient,en plus de l'absence d'indexer, est que tu ne peux pas tester directement la présence d’éléments, tu es obligé de passer par une méthode d'extension Linq qui va énumérer le tout.

Tout à fait! C'est pour ca que je dis que ca dépend de l'utilisation!
Si c'est juste pour faire des foreach...