Discussion :

[bartoumi]

Bonjour
Je veux avoir des argument de pour et de contre pour l'utilisation de méthodes statiques ou non.
L'idée c'est d'avoir une liste d'avantages/inconvénients lié à l'utilisation de methodes statique ou non

D'avance merci

[theMonz31]

salut

en gros

une classe statique,tu peux y acceder de partout..Si tu as des variables globales, ca peut etre interessant de l'utiliser.

Sinon, ca peut se "substituer" à un singleton...

L'avantage d'une classe statique c'est que tu ne l'instancies pas quinze fois. C'est pour moi utile dans le cas de librairie qui fournissent des méthodes de traitement etc... et qui ne seraient pas "forcément" sympa de mettre dans une classe dynamique

Pour moi, l'interet le plus interessant reste l'accessibilité depuis n'importe ou dans le code

(comme la classe Application par exemple)

The Monz, Toulouse

[Graffito]

Imaginons une classe AxeSym dédiée à un axe de symétrie, on aura par exemple :

• le constructeur AxeSym(pt1,pt2) définissanr l'axe
• la fonction PointSymetrique(pt) fournissant le symétrique d'un point,
• ...

Supposons que l'on veuille rajouter dans la classe AxeSym une fonction PointSymStatic(pt,ptA,ptB) qui fournisse le symétrique du point pt par rapport à la droite ptA-ptB : avec une méthode statique, utiliser le constructeur n'est plus indispensable et on peut faire directement appel à PointSymStatic.

[Immobilis]

Salut,

Pour moi, l'interet le plus interessant reste l'accessibilité depuis n'importe ou dans le code

Drole de remarque. Une methode statique est une classe. En tant que tel, l'accessiblité n'est définie que par le modifiers et les références. Je veux dire qu'une classe non static peut aussi être accessible de partout.

L'avantage d'une méthode statique c'est qu'il n'est pas nécessaire d'instancier la classe si elle n'a pas de constructeur.

une classe statique,tu peux y acceder de partout..

Si la classe est static (n'a pas de constructeur et est noté comme static), on ne peut pas avoir deux instances (versions) de la classe. Cela peut poser un pb si on veut faire une collection car toute la collection reférencera la même classe. A vérifier tout de même.

Pour ce qui est de la relation avec le singleton, un singleton est une instance unique d'une classe au niveau de l'application. Le singleton est commun à tous les internautes qui surfent sur un site.

A+

[Guulh]

Euh, suis-je le seul a penser que la question n'a aucun sens ?

Soit la methode est liee tres fortement a un objet (je sais pas moi, maCommandesql.Execute() par exemple), soit elle est "purement" fonctionnelle, c'est a dire qu'elle a n entrees et crache (ou pas) une sortie, en faisant potentiellement un truc rigolo entre les deux (style MessageBox.Show())

Non, vraiment, je comprends pas.

[Guulh]

Drole de remarque. Une methode statique est une classe.

Euh, non... une methode statique est une methode statique. Dans une classe, qui elle peut etre statique ou pas.

Si la classe est static (n'a pas de constructeur et est noté comme static), on ne peut pas avoir deux instances (versions) de la classe.

On ne peut pas en avoir deux parce qu'on ne peut pas en avoir une : les classes statiques ne sont pas instanciables.

Cela peut poser un pb si on veut faire une collection car toute la collection reférencera la même classe.

Ben non on peut pas la referencer parce qu'on ne sait referencer que des instances, et la y'a pas d'instance.

Les classes statiques (CS) n'ont rien a voir avec le sujet du thread. une CS, ce n'est qu'une classe non instanciable et non derivable. Elles ont ete rajoutees au framework dans le seul but (probablement) de representer des "collections" de fonction statiques, a la maniere de System.Math.

[TheBlackReverand]

personnellement j'utilise les "static" dans 2 cas seulement:

1) les cas obligatoir(FindAll, Predicate reclame des static si je ne me trompe...)


2) les fonctions asser general que tu utiliseras asser souvent

exemple: j'ai utiliser une classe static nommer "GenererChaineDeConnexion" avec des fonctions static "MySQL ; SQLServeur ; Access"

ces fonctions generer des chaine de connexion

ainsi dans ma librairie je pouvais, sans me "prendre la tête" avec une instantiation inutile generer mes chaine de connexion

[Immobilis]

Euh, non... une methode statique est une methode statique. Dans une classe, qui elle peut etre statique ou pas.

Oui, je me suis mal exprimé. Une méthode statique est de toutes façons dans une classe. On ne peut y accéder sans faire appel à la classe dont elle est membre. A ce titre elle est accessible, visible comme n'importe quelle classe: suivant ses "modifiers" et la façon dont elle est référencée. Le fait qu'une méthode soit static ne présage rien de son accessibilité.

Ben non on peut pas la referencer parce qu'on ne sait referencer que des instances, et la y'a pas d'instance.

Oui, effectivement.
Pour ne pas perdre de vue la question de départ, vu qu'il n'y a pas forcement bcp d'inconvénients à utiliser des méthodes statiques, peut-être pourrions-nous poser la question dans ce sens: qu'est-ce qui devrait empêcher une méthode d'être statique? Dans quelles conditions devrions-nous d'abords avoir une instance avant d'appeler une méthode?

L'idée serait de tirer profit du constructeur dans lequel il est possible d'executer de manière systematique un morceau de code. Et encore car cela peut-être fait dans la méthode elle-même. Le constructeur n'est jamais qu'une méthode executé systematiquement.

Quand on a une methode static au sein d'une classe instanciable, est-ce que cela ne créé pas une instance implicitement? Heu, non, je viens de faire le test.

Pour: facile à utiliser car pas besoin de l'instancier.
Contre ou plutôt nécessaire d'avoir une instance: quand on doit avoir un objet à manipuler et que la méthode s'execute avec des données contenues dans l'instance.

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
16
17
18
19
20
21
22
public class Class1
{
    public Class1() { }
    public Class1(int a, int b)
    {
        this._a = a;
        this._b = b;
    }
 
    private int _a;
    private int _b;
 
    public int MaMethode()
    {
        return this._a + this._b;
    }
 
    public static int MaMethode(int a, int b)
    {
        return a + b;
    }
}

La methode "MaMethode(int a, int b)" n'a pas le droit d'utiliser "_a" ou "_b".

A+

[Guulh]

Pour ne pas perdre de vue la question de départ, vu qu'il n'y a pas forcement bcp d'inconvénients à utiliser des méthodes statiques,

Evidemment on peut faire tout un programme avec uniquement des methodes statiques. Comme on peut courir le cent metres avec les deux jambes liees. Moins vite, mais on peut. Mais bon, voila quoi. Si on veut pas faire de POO, on fait pas du C#.

peut-être pourrions-nous poser la question dans ce sens: qu'est-ce qui devrait empêcher une méthode d'être statique? Dans quelles conditions devrions-nous d'abords avoir une instance avant d'appeler une méthode?

La notion de statique a un sens parce que la POO est entre autres basée sur la notion d'encapsulation, et que les méthodes d'instance ne sont que des méthodes qui ont acces aux membres privés et prennent de facon masquée un pointeur vers l'instance d'ou vient l'appel.

Donc si une methode a besoin de lire / ecrire des membres d'une classe, autant en faire un methode d'instance de cette classe. Ca permet de mettre un certain nombre de champs en prive, bref on encapsule quoi.

L'idée serait de tirer profit du constructeur dans lequel il est possible d'executer de manière systematique un morceau de code. Et encore car cela peut-être fait dans la méthode elle-même.

Pour completer ce que je disais tout a l'heure, tout ne rentre de pas dans le moule POO (System.Math notamment), ca justifie l'existence de methodes statiques. Mais dans un projet, en volumetrie, c'est tres mineur.

[Immobilis]

Evidemment on peut faire tout un programme avec uniquement des methodes statiques

Du DOS?

La methode "MaMethode(int a, int b)" n'a pas le droit d'utiliser "_a" ou "_b".

Illustré ci-dessus. Ce qui amène une constatation, il n'est peut-être pas utile d'avoir une méthode statique dans une classe non statique puisqu'elle ne peut pas utiliser les membres de la classe. Ce serait un peu un intrus, non?

Dans les deux cas, la classe "Class1" réalise les mêmes opérations. Pourtant, la méthode "MaMethode(int a, int b)" est plus facile à utiliser.

Du coup, une methode statique est interessante dans le cas d'une utilisation "One shot". Une methode non statique accompagnée de son instance est nécessaire pour executer une méthode quand l'objet dans lequel elle se trouve est dans un état bien determiné.

Cela n'a pas forcement de rapport direct, mais FXCop recommande de taguer une classe comme statique si elle ne comporte que des méthodes statiques.

[Max13]

Imaginons une classe personne :

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
16
17
18
19
20
21
22
23
24
25
26
 
public class Personne
    {
        private static int _NbrePersonnes = 0;
 
        public Personne(string nom, string prenom)
        {
            Nom = nom;
            Prenom = prenom;
 
            _NbrePersonnes++;
        }
 
        public string Nom { get; set; }
        public string Prenom { get; set; }
 
        public override string ToString()
        {
            return Prenom + " " + Nom;
        }
 
        public static int CountPersonnes()
        {
            return _NbrePersonnes;
        }
    }

EN plus de vos commentaires, voila la grande force du static dynamic (pour moi).

[neptune]

Je résumerais cela autrement. La différence majeure entre une méthode statique et une non statique est liée à la compilation. Les méthodes statiques provoquent de l'inlining dans le code généré. Il convient donc de les utiliser avec parcimonie car si cela augmente les performances, cela augmente aussi la taille du code généré.

EDIT: le paragraphe précédent est totalement faux... /meaculpa

De plus, l'utilisation des méthodes statiques convient bien pour des fonctions helpers dont on n'a pas besoin de l'orientation objet et de l'encapsulation.

[theMonz31]

salut

perso, j'utilise une classe statique avec des méthodes statiques dans le cadre d'une librairie de traduction...

Comme cela, je centralise via cette classe le chargement de la langue, la gestion de la langue, le déclenchement d'évenement lors d'un changement de langue...

Et du fait, que c'est un statique, ca m'offre une souplesse d'utilisation dans toute mon application...

The Monz, Toulouse

[Guulh]

Je résumerais cela autrement. La différence majeure entre une méthode statique et une non statique est liée à la compilation. Les méthodes statiques provoquent de l'inlining dans le code généré. Il convient donc de les utiliser avec parcimonie car si cela augmente les performances, cela augmente aussi la taille du code généré.

Hein ? Autant que je sache, ca n'a absolument RIEN à voir. L'inlining est un concept de compilation, la "staticité" est un concept objet. La finalité de l'inlining, c'est la perf. Point.

static est un mot-clé traître, il signifie des tas de chose en C, encore d'autres choses en C++, mais au moins en C#, il a un sens bien précis : Un membre static d'une classe est un membre qui n'appartient pas à une instance particulière.

Vive la doc : http://msdn.microsoft.com/fr-fr/libr...dx(VS.80).aspx

[neptune]

La question initiale était pour ou contre l'utilisation de méthodes statiques. Les méthodes statiques (concept objet, je te l'accorde) se traduise en compilation par de l'inlining. Ma réponse donne donc un élément concrêt à la question posée, non?

[Guulh]

Donc j'aimerais bien savoir où tu as vu qu'une méthode statique était inlinée par le compilo. De ce que je sais, il a une heuristique qui lui permet de déterminer s'il faut le faire ou pas, en fonction de la taille de la fonction, notamment. Mais je vois pas pourquoi un concept objet aurait une répercussion sur la compil.
Si tu montres une source, je m'incline

[neptune]

Autant pour moi, j'ai dit une grosse bétise. Les méthodes statiques ne sont pas systématiquement inlinée. Je ne sais pas d'où je tenais cela, et m'excuse pour avoir affirmé des idioties sans les avoir vérifées.

[Keihilin]

Les méthodes statiques provoquent de dans le code généré.

EDIT: le paragraphe précédent est totalement faux... /meaculpa

Non, pas totalement faux. L'inlining est effectivement géré par une heuristique assez complexe et peu prédictible, mais il n'en demeure pas moins que la staticité est une caractèristique qui favorise les chance qu'une méthode soit "inlinée".

Hein ? Autant que je sache, ca n'a absolument RIEN à voir. L'inlining est un concept de compilation, la "staticité" est un concept objet.

et pourtant...les concepts de compilation tiennent compte des concepts objets. La staticité, l'héritage, les membres virtuels; autant de concepts OO qui influent sur la compilation.

[Guulh]

et pourtant...les concepts de compilation tiennent compte des concepts objets. La staticité, l'héritage, les membres virtuels; autant de concepts OO qui influent sur la compilation.

Tout à fait Un concept OO va être réalisé par le compilo (vtable pour les fonctions virtuelles en C++ par exemple), mais il me semble plus sain d'ignorer l'étape bas-niveau qu'est la compilation lorsque l'on designe une fonction. Je préfère du code plus lent d'1% mais lisible et propre qu'une bidouille de la mort rendant le code impossible à maintenir

[Immobilis]

Je préfère du code plus lent d'1% mais lisible

Ca dépend de la fréquence d'execution du bout de code. Ca peut vite tout faire péter.
D'ailleurs, petite question: mettons que j'ai un code dans une seule procédure qui fait 500 lignes. C'est pas très lisible. Ce code met 1s pour s'executer. Il est executé toutes les secondes.
Si j'en extrait les méthodes à un niveau de granularité me permettant d'un seul coup d'oeil de voir la succession des étapes. Disons que je perds 1% du temps d'execussion soit 1 centieme de s.
A la fin de la journée, si je ne me trompe, j'aurais perdu 864s. Il faut savoir si toutes les applications peuvent tolérer ça.

[EDIT]La question: Y a-t-il des stats sur la rapidité en fonction du nombre de méthodes?[/EDIT]

Sinon, un code clair n'engendre-t-il pas un code rapide à executer?


A+