Bonjour,  
 
J'ai eu un petit débat avec mon supérieur qui me reproche d'utiliser le mot "static" dans toutes mes méthodes.  
En fait, dans ma tête, dès qu'une méthode ne dépend pas d'un objet en particulier et ne fait que retourner qqch en fonction de ses input, je la mets en "static".  
Par exemple, je mettrais en static des méthodes qui :  
- ajuste la largeur d'une combobox en fonction de son contenu
- renvoit un Dataset à partir d'une requête SQL
- renvoit un TreeNode[] à partir d'une requête SQL
- instancie et renvoit un datagridview vide
...
 
En fait, je mets "static" chaque fois que la méthode se comporte comme une librairie car utile, et doit être accessible partout.  
Mon supérieur me disait alors : "Ouais mais dès qu'on veut rajouter des statuts, des variables pour modifier le fonctionnement de tes méthodes statiques, bin on peut pas, sauf en passant un tas d'arguments en input de tes méthodes...".  
 
Quelque part, il a raison. Alors si vous pouvez me faire un retour sur tout ça (différence de performance, facilité de codage, maintenance...), ça serait super
Merci d'avance.

je suis d'accord avec toi. Mais je suis également d'accord avec ton supérieur.  
Typiquement, je les utilises comme toi. Les classes dites "Utils" qui permette à partir de l'input, de renvoyer un output.  
 
exemple:
redimentionner une photo, faire des validation de données, etc...  
 
Donc à utiliser dans des cas bien précis. Peut-être pour l'accés db, c'st pas top en effet, la je ne les mettrais pas en static... car la db est très complexe, et il y a moyen de mettre un tas d'options... Mais sinon dans les autres cas, c'est tout à fait justifié.

Merci pour ta réponse
 
C'est bien qu'on soit d'accord. Aussi, un bon compromis entre "static" et "instance" est d'utiliser un singleton.  
Par exemple, si la classe "Tools" a une propriété "Instance" qui retourne l'unique instance de la classe "Tools", et bien tu pourras faire :  

Ainsi, tu n'as pas à créer un objet "Tools" pour utiliser ta méthode, et puis tu peux modifier les propriétés de ton objet "Tools" quand tu le désires
Merci bien à toi.

Pour reprendre tes exemple :
* Une méthode static qui ajouste la taille des combobox en fct de leur contenu
=> c'est pas objet. La façon "objet" de faire c'est de créé ta propre classe dérivée de ComboBox, qui s'ajuste elle-même à son contenu.
 
* renvoit un Dataset à partir d'une requête SQL
=> Je fais pareil (mais j'utilise des procédures stockées). C'est un des rares cas où j'utilise static.
=> et je suis pas d'accord avec moi23372 : si on découpe le code en "couches" comme dans le modèle N-tiers, on dois pas avoir à préciser des tas d'options (ou alors on parle pas des mêmes. t'as des exemples ?)

* renvoit un TreeNode[] à partir d'une requête SQL
=> oulala, le pb c'est le découpage de ton application. Tu connais le N-tiers ?  Là le pb c'est que tu mélanges allègrement la couche "présentation" et la couche "données".
En tant qu'architecte je dirait qu'il y a un pb est dans la conception.
 
* Instancie et renvoie un DataGrid vide.
=> Pourquoi n'utilises-tu pas le constructeur vide ?  Parce que tu veux pouvoir configurer ta DataGrid ? Dans ce cas : même remarque que la première : en objet, on aurait créé une DataGrid héritée et on la configure dans son constructeur.
 
 
Sinon sur les points que tu présentes, c'est un vieux débat entre programmation procédurale et programmation objet.
Autrefois on disait "procédural" pour du code en C ou en Pascal, aujourd'hui on peut l'appliquer au code "tout-static", paske c'est le même raisonnement derrière, seule la façon de ranger le code à changé.
 
* performances : a priori, je dirai que le procédural est plus performant. Il prend moins de RAM (aucun objet en mémoire, que des classes).
Dans quelle mesure ?  Négligeable sauf si tu commences à avoir des milliers d'instances (et encore ça dépend de la machine)
Maintenant, si ton code est complexe, en procédural tu dois parfois stocker plus d'informations dans ta classe (parfois beaucoup plus), pour réussir à faire un code équivalent.
 
* facilité de codage : à bah c'est plus simple de pas coder en objet. L'objet c'est une façon de penser, ça implique un apprentissage, alors que la programmation procédurale c'est plus intuitif.
 
* Puissance : c'est la première raison pour laquelle le procédural est en train de disparaître. Le jour où tu as un projet hyper complexe, en procédural tu vas pleurer ta mère, alors qu'en objet... c'est bien plus facile.
J'ai pas d'exemple dans ma manche, mais si j'en trouve, j'édite ce post.
 
* Maintenance : Ca ne change pas grand chose. Si le mec qui reprend le code est bon en procédural il préfèrera le procédural. Sinon il préfèrera l'autre.
Disons qu'un pro âge de moins de 35 ans critiquera beaucoup le mec qui a tout codé en procédural
 
* Evolutivité : y'a pas photo. En procédural, ton évolutivé est quasi-nulle par rapport aux possibilité d'évolutivité en objet.
Y'a des gens qui seront pas d'accord, mais c'est qu'ils ne maîtrisent pas l'objet.
Désolé d'être aussi affirmatif, mais je suis un puriste de l'objet qui a lutté pendant des années contre de chefs de projets incapables de penser en objet, et franchement on m'a fait faire des milliers de lignes de code de merde là où en 50 lignes de code objet j'aurait pu faire mieux...

plutot que de dériver tout le temps, y'a la composition...je dériverais pas des objets Swing, qui sont plutot complexes...surtout que si un jour tu veux changer la gueule de ton output (passer d'une combo à un textfield par exemple), avec une composition tu changes c facile...avec un héritage, ca te fout en l'air une plus grosse partie du code...

même si dans l'absolu on peut dire qu'une combo auto-redimensionnable EST UNE combo, le problème c'est que ces objets swings sont très dépendants de leur vue ou de méchanisme liés à la vue...

pour en avoir pas mal discuté, et lu des trucs sur le sujet, ce qu'on recommande en général qd on utilise Swing :

- avoir un modèle (ici par ex le contenu de la combo), qui soit un objet java tout con
- avoir un objet selon le design pattern Bridge, qui implémente l'interface du modèle utilisé par le composant Swing (ici un ComboBoxModel)
- un objet java de type Wrapper, qui contient un objet combobox et le bridge...

avec ca, t'as le maximum de découplage, si tu veux changer ta vue, ou le modèle, ca fout pas en l'air toute ta hiérarchie

PS : pour les bases de données, en général je me crée un objet qui contient mes paramètres...si je dois changer mes paramètres, la signature de la méthode qui va faire la requete ne change pas

En .Net ça pose aucun pb de dériver un Control, ils sont faits pour.
En Java je connais pas.
 
Maintenant pour la composition : Non
L'inconvénient c'est que niveau codage, en .Net c'est super relou, ça demande facile de double de travail, paske ton objet doit forcément hériter de control.
Après tu peux t'amuser à wrapper toutes les méthodes et propriétés, mais c'est vraiment pas le pied.
Franchement, l'héritage sincèrement c'est mieux (en .Net je précise). Si jamais tu veux changer ta vue, tu changes le contrôle duquel tu hérite et basta.

je connais pas .NET (j'ai du faire 2-3 merdouilles dessus en cours) donc je sais pas...si l'héritage est imposé je dis pas

Très très intéressant votre débat ! Merci beaucoup    
Effectivement je me suis rendu compte ce matin que j'avais fait du code pourri :  
-> une classe "CustomComboBox" (qui hérite de ComboBox), avec plein de méthodes statiques (de redimensionnement...) ! C'est nul hein ?    
 
Le N-Tiers, j'y connais pas grand-chose... je vais m'y intéresser alors
 
Sinon j'ai une question concernant le fameux "singleton" dont j'ai parlé ds mon 2ème message de ce thread. Ce singleton avec un tas de méthodes "Utilitaires" équivaut exactement à de la programmation procédurale, pas vrai ? Conclusion, le singleton c'est nul ! (Je rigole lol).  
 
Merci bien pour vos conseils !

heu le but même d'un singleton c'est d'éviter que les méthodes soient statique, parce que tu peux t'assurer que tu n'as qu'une et une seule instance de ta classe qui tourne....
 
ca sert beaucoup pour par exemple les discussions avec les bases de données, parce que tu peux garantir que seule une instance parle avec la BDD

Bein... si tu fais du static de partout, c'est complètement inutile

C'est pas imposé, mais c'est bien plus rapide à coder qu'un wrapper.
Après y'a aussi une classe UserControl qui permet de créer ses propres contrôles par composition, qui fourni déjà les outils de base et qui hérite de la classe de base Control.
Mais bon.. pour faire une TextBox custom, l'héritage c'est vraiment le top.