Salut tout le monde,
Quels sont les inconvenients d'utilisations de plusieurs (plus de 15) méthodes partagées (shared) dans une classe ?
Version imprimable
Salut tout le monde,
Quels sont les inconvenients d'utilisations de plusieurs (plus de 15) méthodes partagées (shared) dans une classe ?
?
aucun ...
meme si ces methodes sont utilisées au meme temps par plusieurs utilisateurs dans un environnement de production ?
pourquoi voudrais tu qu'il y ait un inconvénient ?
enfin le fait qu'une méthode soit shared ca ne fait rien de mal ... une méthode c'est une méthode qu'elle soit shared ou pas
après si tu veux parler de multithreading, là on peut trouver des inconvénients qui peuvent engendrer des problèmes en environnement de production
Précisément, une méthode statique ("Shared" en VB.Net) ne pose aucun problème en multithread si elle n'accède à aucune variable statique.Citation:
Envoyé par Pol63
une méthode non statique ne pose pas non plus de problème en multithreading si elle n'accède à rien d'extérieur ...
Mais je n'ai rien dit laissant entendre le contraire :DCitation:
Envoyé par Pol63
Sauf que rien d'extérieur n'est pas une condition suffisante (si tu veux dire rien d'extérieur à la classe, bien sur)
En effet, une méthode d'instance accédant à un/des membres d'instance n'est pas naturellement "thread safe" (de même qu'une méthode statique accèdant à un/des membres statique/Shared).
Seulement, une méthode d'instance n'accédant à aucun membre d'instance est en effet "thread safe" mais ne devrait pas être déclarée en temps que méthode d'instance et devrait l'être en tant que méthode statique. (Shared). (le contraire est une faute -vénielle, il est vrai- de design).
mais je n'ai rien dit laissant entendre que tu laissais entrendre le contraireCitation:
Envoyé par Bluedeep
:roll::aie:
m'enfin oui t'as pas tord, une méthode qui n'accède à rien doit être statique ^^
Oui, car il y a une (légère) différence de perf.Citation:
Envoyé par Pol63
Pas vraiement d'accord avec le terme "doit" d'un point de vue conceptuel.Citation:
m'enfin oui t'as pas tord, une méthode qui n'accède à rien doit être statique ^^
Il est possible dans certains cas que la fonction en évoluant utilise une propriété de l'objet. Ce n'est donc pas un critère déterminant pour savoir si une méthode doit être déclarée statique ou pas.
Cet argument est en effet recevable.Citation:
Envoyé par sinople
oui et non, une évolution en général on ne la connait pas à l'avance
sinon soit on la fait tout de suite, soit on fait du code temporaire, et donc là en effet on pourrait la laisser non static
mais de toute facon une évolution c'est une modification de code, donc rendre la méthode non static à ce moment là peut etre intégré dans la modification
mais bon je chipote surement ^^
Sauf que si tu la mets non static du début le jour où tu utilises une propriété de l'objet tu n'auras pas à modifier le code client, alors que si tu la mets static et que tu la passes en méthode d'instance ça te change tout le code client. Si tu fais une bibliothèque par exemple c'est pas acceptable. Donc c'est au niveau conceptuel que ça se décide.Citation:
Envoyé par Pol63
Bonjour e1230,
La question que tu devrais te poser, c'est pourquoi as-tu autant de méthode de classe(shared, static) ?. Le but de programmer avec un langage orienté objet, c'est d'abord de faire la maintenance de l'état des objets. Donc, à moins d'avoir une classe contenant des méthodes utilitaires comme par exemple Math et dans certains cas particuliers, tu ne devrais pas avoir recours à ce type de méthode.
De plus, dans la plupart des cas, l'évolution est beaucoup plus difficile à partir des méthodes de classe puisqu'elles s'intègrent mal dans la logique des "Design patterns".
Je t'invite donc à te renseigner sur les "Design Patterns" et la conception d'un modèle objet en général.
Et fais attention à VB.net, beaucoup de gens utilisent VB.net comme vb6 alors qu'ils devraient se baser sur C# ou java.
Bonne journée
DoOmX
Merci à tous et particulierement doomx