Discussion :

[olibara]

Bonjour

Bon je sens que je vais de nouveau ouvrir un debat et je n'oserais meme pas dire que ce débat n'a pas déja eu lieu mais je ne retrouve pas

Dans une app je devrais avoir a disposition une serie de petites methodes outils accessible partout !

J'aurais tendance a les mettres dans une classe publique statique
Mais je sais aussi que certains préconiseront ardament le singleton !

Quelqu'un voit-il d'autres alternatives ? ou aurait une suggestion pour faire pencher la balance ?

Merci de vos suggestions

[NotANumber]

Bonjour,

Pour moi, si il y a un choix à faire c'est en fonction de ce que l'on veut y mettre...

[olibara]

Juste des methodes de traitement générique ! :

Dans une app je devrais avoir a disposition une serie de petites methodes outils accessible partout !

[Guulh]

Ca dépend de l'ampleur de ton projet, mais l'un comme l'autre couplent très fort les classes entre elles.

Si c'est une collection de méthodes, dont l'implémentation ne changera jamais (l'exemple typique étant System.Math), tu peux y aller avec une classe statique. Ou un singleton, c'est du pareil au même, à quelques détails de multithreading près. Même si le singleton t'offre une souplesse supplémentaire : pour une classe Singleton "Truc", tu peux faire évoluer ta classe pour que la propriété "Instance" ne retourne plus une instance de Truc mais d'une de ses filles.

Sur un projet plus costaud, que l'on voudra modulariser le plus possible, avoir un lien aussi fort (puisque les classes appelante connaissent le nom exact de la classe statique / du singleton) empêche de changer simplement l'implémentation de ta classe Truc. Et ça empêche l'injection de dépendance, bien aimée des tests unitaires

Donc, AMHA, si tu as juste une collection de méthodes liées par une thématique commune mais indépendantes, et que ta classe n'a pas d'état (i.e. de propriété / de membre public), tu peux pallier au manque de fonction "libre) (i.e. hors classe) propre à java et C#, et les mettre dans une classe statique. Si c'est un vrai objet, non immuable, c'est pas super pérenne.

[olibara]

Merci Guuhl,

Bon je vais y aller pour une classe statique .

Mais une question me vient quand meme a l'esprit
Que fais le FW avec les methodes d'une classe 'normale' lorsque celle ci est instancieé plusieurs fois ?

J'avais cru a un moment que que les methodes etaient instancie autant de fois !
Quelqu'un m'a détrompé (Tomlev je crois) pour me signaler que les methodes n'etaient intancieés qu'une seule fois (en tout cas dans un meme thread) et que chaque instance de la classe faisait référence au meme code.

Si c'est vraiment le cas le fait de rassembler les methodes outil dans une classe statique n'apporte pas grand chose si ce n'est le lien fort pas tres recommandable que tu évoque.

[Guulh]

Un méthode, c'est une méthode. Ce n'est pas instancié. Ce n'est pas dans la même mémoire que les objets.

Une méthode membre, ce n'est qu'une méthode classique (au sens C du terme) ayant en paramètre caché un référence vers l'instance de la classe à partir de laquelle elle est appelée. C'est juste qu'elle a des droits d'accès vers les membres privés et protégés de la classe.

Code :

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

1
2
3
4
5
6
7
class Truc
{
  public int i;
  public int GetTriple() { return i * 3; }
}
 
public int GetTrucTriple(Truc t) { return t.i * 3; } // tout pareil

Après, y'a la question des méthodes virtuelles, puisqu'à chaque instance est associée une vtable, indiquant quelle surcharge de la méthode utiliser. Mais même dans ce cas là, ce qui est stocké, c'est un "pointeur" vers la méthode. Et encore, le JIT compiler doit faire pas mal d'optims pour "dévirtualiser" certaines méthodes.

Donc, pour un bout de code donné, choisir où on le met (dans la classe, statique ou pas, dans une classe externe, ...) doit uniquement se faire en termes de design, pas de gestion de la mémoire ou des perfs.

[olibara]

Donc, pour un bout de code donné, choisir où on le met (dans la classe, statique ou pas, dans une classe externe, ...) doit uniquement se faire en termes de design, pas de gestion de la mémoire ou des perfs.

Bingo !

Effectivement c'est bon a savoir, et souvent ignoré

Merci Guuhl