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

[ptilemare]

Bonjour à tous !

Je déterre ce post pour continuer la discussion
Je suis confronté à la même problématique. Seulement, il y a eu des nouveautés dans C#, et travaillant en web avec le Framework .NET 4.0, je me demandais si il y avait d'autres alternatives.

Voici mon cas, et ce que j'ai pensé :

J'ai aussi pensé directement à une classe statique. J'ai des méthodes outils comme une qui me retourne un hashset de x couleurs aléatoire en fonction d'un nombre x en entrée.

Seulement, le projet est voué à être développé pendant un moment et va grossir à une allure assez impressionnante. Arrêtez moi si je me trompe mais une classe statique est chargé en mémoire côté serveur même si l'on ne s'en sert pas, à contrario d'une classe standard qui est chargée lors de l'appel de son constructeur, non ?

Pour le singleton, je ne me suis pas penché dessus.

Autrement, prendre une classe standard, appeler la méthode et détruire directement l'instance, ça permettrait de ne pas charger en mémoire inutilement et d'avoir tout de même une classe avec méthodes outils, n'est-ce pas ?

Merci d'avance pour vos remarques !
Qu'en pensez-vous ?

[olibara]

Si tu relis la réponse de Guullh, elle te donne déja la réponse !

[ptilemare]

Et avec les nouveautés du Framework .NET depuis cette date, aucune autre solution n'est vraiment révolutionnaire pour ce cas ?

Merci en tout cas Je vais donc faire une classe statique Passe ton sujet en résolu

[Guulh]

J'ai écrit ça, moi ? me souvenais plus...

Arrêtez moi si je me trompe mais une classe statique est chargé en mémoire côté serveur même si l'on ne s'en sert pas, à contrario d'une classe standard qui est chargée lors de l'appel de son constructeur, non ?

Le code de ta classe statique est bien chargé en mémoire, mais c'est micro-pico-peanuts que dalle. Ce n'est pas le code qui prend de la place mémoire, ce sont les instances d'objet et ce qu'ils contiennent.

Donc, je me répète:

Une 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.

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.

Pour compléter.
Un autre facteur important est le suivant: est-ce que tu peux concevoir une autre implémentation de cette méthode ? est-ce qeu tu vas vouloir mocker cette fonctionnalité dans un test ?
Si c'est le cas, tu as intérêt à définir une interface, avec ta méthode HashSet<Color> GetRandomColors(int count) dedans.

Après, ce genre de décision n'est pas gravé dans le marbre. Tu peux commencer d'une façon et refactoriser pour basculer après. Avec les outils de refactoring de base de Visual Studio c'est faisable (bien qu'un peu pénible), avec un outil comme resharper c'est tout simple.

[sisqo60]

Bonjour,

Je me permet d'ajouter une remarque à tout ce qui a été dit.
Pourquoi ne pas tout simplement utiliser les méthodes d'extension (oui certes dans une classe statique), mais cela permet de rester purement objet et ainsi d'étendre uniquement les classes que l'on désire.

Pour continuer avec l'exemple de Guulh :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
public static class Extensions
{
     public static int GetTriple(this int unEntier)
     {
          //On peut vérifier qu'en multipliant, on ne dépasse pas la valeur max d'un entier etc...
          return unEntier * 3;
     }
}
 
//à l'utilisation ça donne ça:
int monEntier = 10;
int leTriple = monEntier.GetTriple();

Je suis amateur des méthodes d'extension, et on veut souvent voire toujours étendre des fonctionnalités qui n'existent pas dans des classes, donc autant respecter le développement objet à l'aide des méthodes d'extension.

Bon dév à tous

[Guulh]

Pourquoi ne pas tout simplement utiliser les méthodes d'extension (oui certes dans une classe statique), mais cela permet de rester purement objet

Les méthodes d'extensions sont parfois justifiées, mais ce n'est qu'un sucre syntaxique (bon, comme toute la POO me direz-vous...), qui n'a aucun impact sur l'encapsulation, et à ce titre ne sont pas plus "objet" que des méthodes statiques classiques.

[MaximePalmisano]

Pourquoi ne pas tout simplement utiliser les méthodes d'extension (oui certes dans une classe statique), mais cela permet de rester purement objet

A la compilation, une méthode d'extension est transformé en son équivalant statique.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public bool IsEmpty(this string s)
{
return s == "";
}
 
public void Foo()
{
    if(toto.IsEmpty()) // Sera remplacé à la compil par IsEmpty(toto);
    {
         // Do something
    }
}

Du coup, ça ne change rien du coupling, juste la lisibilité.


Pour en revenir au sujet, j'aime bien avoir des classes "Helpers" ou des méthodes d'extensions qui factorisent des traitements récurrents sur des classes que je ne maitrise pas.

Attention cependant, on se retrouve vite avec un fourre-tout où les gens mettent leurs fonctions par flemme histoire de pas avoir à modifier les classes.

Donc oui aux classes statiques helpers et méthodes d'extensions, non au fourre-tout transverse.

[sisqo60]

Pardon, j'ai pas été très précis... Purement objet dans l'utilisation (à l'ajout d'un namespace près ). Mais conceptuellement et techniquement parlant cela revient quasiment au même que les classes statiques standard, à la nuance près qu'à l'utilisation, on appelle une méthode étendue de l'instance de la classe à laquelle on se réfère.

Je préfère aussi les méthodes d'extension pour le fait que l'on ait pas à chercher dans toutes les classes outil (pour l'avoir vu dans pas mal de gros projets) la ou les méthodes qui nous intéressent. L'avantage c'est qu'on a besoin uniquement à la ou les chercher dans les propriétés disponibles de l'objet que l'on souhaite utiliser (toujours à l'ajout d'un namespace près).