Discussion :

[Guulh]

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

Malheureusement non.

Tu prends un cas extrême Il n'est pas évident de bien placer le curseur entre du code très lisible mais pas optimal et du code incompréhensible mais plus rapide d'1%.

Mais l'optimisation est l'étape finale d'un développement. Si on constate un goulot d'étranglement dans un workflow, on peut justifier l'utilisation de méthodes "non canoniques", mais optimiser prématurément sans commenter, et ceux qui liront le code plus tard pour le maintenir (c'est à dire soi-même la majorité du temps d'ailleurs) vont se gratter la tête en disant "mais qu'est-ce que j'ai bien pu vouloir dire ?"

Linq en est un parfait exemple : il simplifie la compréhension du code, au prix d'une légère perte de perf, si je me trompe pas. Mais le code étant plus lisible, on gagne du temps de maintenance qui peut être utilisé pour améliorer l'infrastructure du soft par exemple.

J'en ai vu du code, qui faisait des optimisations (qui gratte 1% de perf une fois sur mille) aux petits oignons sur les collections, ça l'a pas empêché d'être bourré de fonctions en complexité quadratique alors qu'elle pourrait être linéaire par exemple.

[Onlava]

Personellement je définis souvent des membres statiques à l'intérieur d'objets instanciables.

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
class Personne
{
public string nom
...
public int age
 
public static List<Personne> Liste;
 
public static LoadAll()
{
    //désérialize une liste depuis un fichier
    //et l'attribue à Liste
}
 
public static List<Personne> Find(parametre)
{
    //... fais une recherche et renvoie une list de résultats
}

Du coup j'ai le manager et les objets dans la meme classe. Sympa pour les trucs "vite faits" pas trop complexes

Code :

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

1
2
3
4
Personne.LoadAll();
Personne.List.Add(new Personne(machin))
List<Personne> resultats = Personne.Find(trucbidule)
etc..

}

[Immobilis]

Du coup j'ai le manager et les objets dans la meme classe. Sympa pour les trucs "vite faits" pas trop complexes

Interessant, quel est le degré de complexité à partir duquel cela n'est plus valable à ton avis?
A+

[Onlava]

Je dirais que c'est pratique que si le manager doit gérer un seul type d'objets indépendament du reste de l'application, et que les méthodes se limitent a des choses simples (load/save/process/search)
Par exemple pour une classe de configs.

[Immobilis]

Je dirais que c'est pratique que si le manager doit gérer un seul type d'objets indépendament du reste de l'application, et que les méthodes se limitent a des choses simples (load/save/process/search)
Par exemple pour une classe de configs.

Est-ce que tu peux développer un peu plus?
Je conçois que c'est pratique, as-tu des exemples du cas contraire?

A+

[bartoumi]

Bonjour
Apparement j'ai lancé un debat sur un sujet tres complexe !!
Ce que je cherche moi exactement

C'est l'impact sur :
1- La gestion de memoire.
2- Les performances(en generale).

et aussi est ce qu'il y'a des regle(recommandéou bonnes pratique) du choix entre methode Statique ou non.

Merci

[Keihilin]

C'est l'impact sur :
1- La gestion de memoire.
2- Les performances(en generale).

Il n'est pas évident d'être catégorique sur les avantages d'une méthode statique, mais en gros :

• Une méthode statique est souvent une bonne candidate à l'inlining.
• Une méthode statique n'existe qu'une seule fois en mémoire, mais elle existe dès le début et existe pendant toute le vie du programme.

Donc, à priori, une méthode statique favorise les performances, ne serait-ce que parce que son chemin d'appel est connu et ne peut pas varier.
Niveau mémoire, c'est difficile à dire...

Les outils d'analyse comme FxCop suggère de passer une méthode d'instance en méthode statique dès lors qu'elle n'utilise pas de membres d'instance dans son traitement.
Après à toi de voir si cela se justifie ou si ton design peut être amélioré.

[tomlev]

Une méthode statique n'existe qu'une seule fois en mémoire

Donc, à priori, une méthode statique favorise les performances, ne serait-ce que parce que son chemin d'appel est connu et ne peut pas varier.

Certes... mais c'est vrai aussi pour une méthode d'instance : le code d'une classe est présent une seule fois en mémoire, il n'est pas dupliqué pour chaque nouvelle instance. La seule différence est qu'une méthode d'instance reçoit implicitement this en paramètre, contrairement à une méthode statique.

Donc le fait qu'une méthode soit statique ne change rien aux performances à mon avis...

et aussi est ce qu'il y'a des regle(recommandéou bonnes pratique) du choix entre methode Statique ou non.

Pour moi, ça dépend essentiellement si la méthode est liée ou non à une instance particulière d'objet. Typiquement, une méthode qui renverrait des informations globales à l'application serait statique, par exemple :

Code :

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

1
2
3
4
public static string GetConfigurationPath()
{
    ...
}

[Immobilis]

La discussion http://www.developpez.net/forums/sho...d.php?t=248877 aborde aussi plus ou moins la question. Pouvez-vous jeter un oeil?

Merci d'avance.

[tomlev]

La discussion http://www.developpez.net/forums/sho...d.php?t=248877 aborde aussi plus ou moins la question. Pouvez-vous jeter un oeil?

Merci d'avance.

Je ne vois pas vraiment le rapport... cette discussion ne parle pas de méthodes statiques d'après ce que j'ai vu

[Immobilis]

Ben si un peu.
Le question du post actuel étant: "methodes statique Avantages/ inconvénients", on peu facilement dériver sur des questions d'architectures.

A+

[Keihilin]

Certes... mais c'est vrai aussi pour une méthode d'instance : le code d'une classe est présent une seule fois en mémoire, il n'est pas dupliqué pour chaque nouvelle instance.

Je ne voulais pas dire que le code d'une classe est forcément dupliqué, mais par le jeu des mécanismes d'héritage, il peut l'être.
Sans rentrer dans les détails trop techniques (que je ne maîtrise pas forcément à 100% de toute manière), la pile d'appel d'une méthode d'instance est forcément plus complexe que celle d'une méthode statique (d'où l'utilité du mot-clé "sealed" pour indiquer au compilateur qu'il n'a pas besoin de se soucier d'éventuels enfants).

[Guulh]

Je ne voulais pas dire que le code d'une classe est forcément dupliqué, mais par le jeu des mécanismes d'héritage, il peut l'être.

Si la méthode est virtuelle uniquement. Faudrait vérifier si Convert.ToString(4) et 4.ToString() ont des perfs différentes. J'ose espérer que non

[Keihilin]

Si la méthode est virtuelle uniquement.

Je ne crois pas. N'oublions pas que même si une méthode n'est pas virtuelle, elle peut être redéfinie...

Faudrait vérifier si Convert.ToString(4) et 4.ToString() ont des perfs différentes. J'ose espérer que non

Sur une opération aussi simple, il n'y a aucune différence...j'ai testé

[Guulh]

Je ne crois pas. N'oublions pas que même si une méthode n'est pas virtuelle, elle peut être redéfinie...

Euh, comment ? Tu penses au mot clé new ? Si c'est le cas, je ne pense pas qu'il intervienne dans notre problématique, par ce que le compilo sait statiquement s'il faut appeler la version de base ou la version "newée". ce qui n'est pas le cas bien sûr pour les méthodes virtuelles.

[Keihilin]

Euh, comment ? Tu penses au mot clé new ? Si c'est le cas, je ne pense pas qu'il intervienne dans notre problématique, par ce que le compilo sait statiquement s'il faut appeler la version de base ou la version "newée".

Oui, je pensais bien à "new".

Possible que tu ais raison, je ne suis pas très sûr de la façon dont cela est géré par le compilateur...

Il faudrait que je vérifie par curiosité, mais plonger dans du MSIL un lundi matin, c'est au dessus de mes forces

[SirJulio]

Salut,

meme en faisant un masquage (aka new) et en sealant l'objet, l'appel reste virtuel (alors qu'on pourrait le resoudre à la compilation). En IL, on peut appeler les methodes soit statiquement (opcode call) soit en laissant le runtime resoudre le type (qui est fait à partir du this passé en caché en premier argument). La norme dit bien qu'on peut appeller des methodes d'instances de maniere statiques :

It is valid to call a virtual method using call (rather than callvirt); this indicates that the method is to be resolved using the class specified by method rather than as specified dynamically from the object being invoked. This is used, for example, to compile calls to “methods on super” (i.e., the statically known parent class).

Mais malgré la possibilité il semblerait que csc n'emette quasiment jamais de call statique (meme en release) et prefere deleguer la resolution du type au runtime. meme sur un pattern de ce type :

Code :

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

1
2
3
4
5
6
7
sealed class Truc : Base
    {
        public new string ToString()
        {
            return iM++.ToString();
        }
    }

On pourrait imaginer un call statique, vu que le jeton ToString est ajouté explicitement par la classe, et que cette derniere est finale, mais non :

Code :

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

1
2
3
4
5
6
7
8
 //...
    L_0000: newobj instance void ConsoleApplication1.Truc::.ctor()
    L_0005: stloc.0 
    L_0006: ldloc.0 
    L_0007: callvirt instance string ConsoleApplication1.Truc::ToString()
    L_000c: pop 
 
    //...

Ceci dit il y a un avantage au new , si on le remplace par un simple override, l'IL emit devient :

Code :

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

1
2
3
4
5
6
 
    L_0000: newobj instance void ConsoleApplication1.Truc::.ctor()
    L_0005: stloc.0 
    L_0006: ldloc.0 
    L_0007: callvirt instance string [mscorlib]System.Object::ToString()
    L_000c: pop

ou la le runtime doit à la fois resoudre le type (la variable locale 0 est ici de type truc), et chercher la methode candidate.

Bref, j'ai l'impression que la plupart du temps, le compilo C# prefere laisser le boulot au runtime, et ne lie statiquement que les methodes statiques (qui par definition sont statiques (sic)). Concernant les impacts en termes de perfs de la resolution des candidats ni la norme, ni les quelques livres parlant de la CLR (Essentials .Net : The CLR; Expert .Net 2.0 IL Assembler) n'en parle, ce qui à mon avis doit etre negligeable (du moins en milieu managé, ou des differences de cet ordre sont noyé dans la masse).

[bartoumi]

Désolé
Mais personne ne m'a répondu a ma question ?

Impact sur les performance ?
Gestion de mémoire?
Y'a t'il des règles de choix?

Si quelqu'un a une référence de documentions , j'aimerai bien qu'il me fasse part.

Seul certitude : En statique on fait pas de l'objet on fait du procédural

Parce qu'il faudra clore un moment ou un autre sujet.

[Guulh]

Désolé
Mais personne ne m'a répondu a ma question ?

Euh...

Concernant les impacts en termes de perfs de la resolution des candidats ni la norme, ni les quelques livres parlant de la CLR (Essentials .Net : The CLR; Expert .Net 2.0 IL Assembler) n'en parle, ce qui à mon avis doit etre negligeable (du moins en milieu managé, ou des differences de cet ordre sont noyé dans la masse).

Seul certitude : En statique on fait pas de l'objet on fait du procédural

Non, le concept de "static" a aussi du sens en objet. Toute fonction n'a pas besoin des membres d'une instance particulière.

Gestion de mémoire?

Hors sujet : une méthode est un bout de code, présent une seule fois en mémoire (hors inline).

[bartoumi]

Merci

Par personne n'a répondu à ma question. je veux dire avec de vrai arguments technique pas ce que les personne pense

Par la gestion de mémoire. je veux dire tout les objets qu'on serait amener à créer a l'intérieur de la méthode (statique ou non)

Et je confirme faire du statique ce n'est pas de l'objet.(conseil : merci de bien réviser les concept objet)