Discussion :

[maa]

Bonjour,

J'ai depuis longtemps un flou sur ce qu'est réellement une classes static.
Mon problème n'est pas de savoir comment elle se comporte, mais plutôt ce qu'elle représente et sur ce qui se cache derrière :

• Un programmeur m'a dit une fois qu'une classe static est simplement une classe qui ne possède qu'une seule instance que l'on ne contrôle pas et qui est crée par le constructeur static lors de la première utilisation de la classe.
  Pour ma part, j'ai l'impression qu'il n'y a pas création d'objet avec de telles classes car on travaille directement sur le type... Est-ce qu'au niveau MSIL, une classe static est traduite comme une classe n'ayant qu'une instance ? Mais alors, à quoi peut-on rattacher une classe static dans le monde réel ? Je veux dire qu'est-ce qu'elle représente concrètement ? Ou bien n'est elle utile que pour la programmation sans avoir réellement de signification ?
  
• J'ai l'impression que les classes statiques sont là pour combler tout ce qu'on ne peut pas faire en programmation objet et qui est pourtant indispensable : on y met des des méthodes prenant en paramètre des objets que l'on ne peut hériter (comme des objets de type string) (on peut même maintenant "tricher" avec des méthodes d'extensions), des variables globales... Peut être y t-il d'autre cas typique d'utilisation de classe statique ?
  
• Une autre question que je me pose : pourquoi les avoir appelées "static" ? Est-ce en opposition avec le polymorphisme des classes "normales" à l'exécution ?
  
• Enfin, pourquoi ne peut on pas binder une classe statique à des contrôles, pourquoi ne peut-on pas la sérialiser ?

Si quelque un peut m'éclaircir sur ces points...

Merci d'avance.

mathmax

[tomlev]

Un programmeur m'a dit une fois qu'une classe static est simplement une classe qui ne possède qu'une seule instance que l'on ne contrôle pas et qui est crée par le constructeur static lors de la première utilisation de la classe.

Il s'est planté... aucune instance n'est créée. Il y a effectivement un constructeur statique, qui initialise les membres statiques de la classe, mais tu ne peux pas créer d'instance. Celà dit, d'un point de vue fonctionnel ça revient un peu au même qu'une classe avec une instance unique.

J'ai l'impression que les classes statiques sont là pour combler tout ce qu'on ne peut pas faire en programmation objet et qui est pourtant indispensable

Comme je le vois, ça sert surtout à regrouper des fonctionnalités qui ne se rapportent pas à un objet en particulier. C'est généralement des classes "utilitaires".

Enfin, pourquoi ne peut on pas binder une classe statique à des contrôles, pourquoi ne peut-on pas la sérialiser ?

Le binding se fait sur une instance d'objet, or dans ce cas il n'y en a pas. Même chose pour la sérialisation : tu ne peux pas sérialiser un objet qui n'existe pas...

[theMonz31]

salut

par contre, rien n'empeche de sérialiser des choses dans une classe statique

The Monz, Toulouse

[Keihilin]

Celà dit, d'un point de vue fonctionnel ça revient un peu au même qu'une classe avec une instance unique.

Si on veut...
Pour le développeur qui va utiliser ta classe, il est clair que le comportement semble similaire entre une classe statique et un singleton.

Pour le compilateur par contre, la différence n'est pas négligeable...

Puisqu'une classe statique ne peut pas être héritée, on est sûr du chemin d'exécution de ses méthodes. Du coup, une classe statique devient une candidate prioritaire pour "l'inlining".

C'est d'ailleurs l'une des raisons pour lesquelles il faut souvent refléchir un minimum au moment de choisir entre instantiable et statique. Sauf erreur de ma part (il faudrait que je vérifie), en .Net une classe statique est systématiquement "inlinée", ce qui peut conduire à une chute des performances assez dramatique.

[maa]

Du coup, une classe statique devient une candidate prioritaire pour "l'inlining".

Qu'est ce que l'inlining ?

Le binding se fait sur une instance d'objet, or dans ce cas il n'y en a pas.

Oui j'ai bien compris, mais qu'est ce qui empêcherait réellement de pouvoir le faire. Ne pourrait-on pas étendre aussi le binding aux classes statiques ?

Puisqu'une classe statique ne peut pas être héritée, on est sûr du chemin d'exécution de ses méthodes.

C'est ce que je sens aussi. J'oppose cela au ploymorphisme des classes normales et c'est comme cela que je m'explique qu'on les appelle "static".

Si par exemple, on a une application avec plusieurs form. Et des objets qui doivent être manipuler dans toutes ces form. Pour ma part, j'exposerais ces objets dans une classe statique et je les instancierais dans le constructeur statique de cette classe. Est-ce vraiment la façon classique de procéder ?

[Keihilin]

Ca veux dire quoi ?

"L'inlining" est une optimisation utilisée par le compilateur.

Pour résumer on peut dire que l'inlining, c'est le remplacement d'un appel de fonction par une copie de son corps.

Les avantages sont nombreux, les surcoûts de l'appel sont évités : les instructions call et return, la sauvegardes des registres, le passage de paramètres et l'ajustement de la pile n'ont plus lieu d'être.

Il convient par contre de trouver un juste milieu car la forte expansion du code peut conduire à une dégradation des performances.

[Contrec]

Le fait de creer une classe statique et d'y mettre toutes les methodes "utiles" n'appartenant a aucune autre classe d'un projet est-il une bonne chose, ou alors est-ce a eviter?

(performances, memoire, mauvaise utilisaton du static...)

Personnellement je m'en sert pour declarer quelques objets utilisable partout dans le projet ainsi que des methodes utiles (dates, formatage, parcours de grilles, tableaux etc...).

[ced600]

Bah je crois que sur le site de microsoft, il est écrit que les classes static sont à utiliser pour définir les méthodes utilisable par plusieurs classes et non une seule.
Un peu comme une librairie ou une dll sauf qu'à la différence tu peut y mettre des méthodes spécifiques au projet. Par exemple tu peu rendre ta classe gérant la couche d'accés au données statiques ou la classe de contrôle de la classe précédente..

[maa]

Personnellement je m'en sert pour declarer quelques objets utilisable partout dans le projet ainsi que des methodes utiles (dates, formatage, parcours de grilles, tableaux etc...).

C'est un peu la question que je me posais aussi quand je disais :

Si par exemple, on a une application avec plusieurs form. Et des objets qui doivent être manipuler dans toutes ces form. Pour ma part, j'exposerais ces objets dans une classe statique et je les instancierais dans le constructeur statique de cette classe. Est-ce vraiment la façon classique de procéder ?

[ced600]

Si par exemple, on a une application avec plusieurs form. Et des objets qui doivent être manipuler dans toutes ces form. Pour ma part, j'exposerais ces objets dans une classe statique et je les instancierais dans le constructeur statique de cette classe. Est-ce vraiment la façon classique de procéder ?

Je dirais que c'est une bonne façon de procéder, et cela ressemble à la façon décrite par MS. A mon avis il suffit d'aller faire un tour sur le site MSDN pour avoir la meilleur façon d'utiliser les objets .net et la bonne façon de programmer en .net.

[Contrec]

On est donc sur la bonne voie. D'ailleur cela justifie le role de classes statiques dans un projet.
Je n'ai pas de ralentissements lors du lancement de l'application et j'evite ainsi de creer les memes objets plusieurs fois. Cela dit, il faut etre un peu ordonne car du coup on peu se servir d'une classe statique pour y mettre tout et nimporte quoi...

[cinemania]

tu as posé une question : pourquoi "static" plutot qu'un autre mot genre "virtual" car après tout une classe statique est virtuelle au sens où elle n'a pas d'existance propre vue qu'elle n'a pas d'instance.

déjà le mot virtual fait office au méthodes virtuelles (celles suceptibles d'etre surchargées dans les héritières) et fait référence au fait que la liaison n'est plus statique et déterminé à la compilation, mais bien à l'exécution car virtuelle au moment de la compilation.

Le mot clé static joue le meme role ici, on se place du point de vue du compilateur. une classe static est une classe que le compilateur manipule de façon statique, (comme l'inlining par exemple) l'espace alloué à chacun de ses membre ne l'est pas dans le tas, mais directement dans le code ou le segment de données, et ces emplacements sont immuables, leur "offset" est connu à la compilation, aucun mécanisme de pointeur de retour dans le chainage objet ni rien, d'ailleurs il n'y a pas de cadre objet, autour de ces membres, ils existent et c'est tout, c'est donc le contraire de dynamique et bien statique d'où l'utilisation du mot "static".

Néanmoins là on est plus dans la phylosophie qu'autre chose.

Moi j'utilise les classes statiques soit pour y mettre des données accessible par tout le programme, soit comme collection de fonctions toutes indépendantes l'une de l'autres, et souvent sans rapport aucun entre elles,
comme une classe statique Tools qui comprend des tonnes de fonctions de conversions, de changements de normes et je ne sais quoi d'autre.

Cependant, attention toutefois entre l'utilisation d'un Singleton et d'une classe statique. il est vrai que la limite entre les deux peut paraître floue, mais en réalité, les implications n'étant pas les memes, les usages non plus.

[Maniak]

Cependant, attention toutefois entre l'utilisation d'un Singleton et d'une classe statique. il est vrai que la limite entre les deux peut paraître floue, mais en réalité, les implications n'étant pas les memes, les usages non plus.

Vi, je vois deux exemples en particulier.

En asp.net, une classe statique est 'commune' à toutes les requêtes d'une même application. Donc les valeurs statiques qui peuvent être stockées dedans sont appliquées à tout le monde, et il faut notamment faire très attention aux verrous.
Avec un singleton, on peut stocker l'instance au niveau d'une seule requête pour éviter les éventuels conflits.

Côté tests unitaires, l'instance d'un singleton peut être remplacée par une 'fausse' instance qui simule le fonctionnement normal du singleton (notamment en évitant les accès au disque ou à la base). Avec une classe statique, pas moyen. On ne peut pas passer par une interface, on est obligé de se taper la 'vraie' classe. Si elle fait appel à des ressources externes, ça alourdit monstrueusement les tests unitaires du code qui l'utilise.


Ah et donc, un singleton peut profiter de l'héritage. Une classe statique non.
Mais une classe statique est une chouette simplification syntaxique quand on n'a pas besoin de plus de subtilité.

À consommer avec modération en somme.

[Guulh]

tu as posé une question : pourquoi "static" plutot qu'un autre mot genre "virtual" car après tout une classe statique est virtuelle au sens où elle n'a pas d'existance propre vue qu'elle n'a pas d'instance.

Il me semblait avoir lu quelque part sur ce site que le concept de classe statique est propre à C#, et n'existe pas en .Net. Tel que je le comprends, elle n'a rien de virtuel : c'est juste que son unique instance est créée quelque part entre le début de l'appli et le premier appel à un membre. Quant à l'inlining, eh bien je n'en sais rien.

Mais ça n'a rien de neuf : on pouvait déjà ne définir que des membres statiques dans une classe en c++ ou .Net 1.1, mettre son constructeur en privé et zou

[The_badger_man]

Mais ça n'a rien de neuf : on pouvait déjà ne définir que des membres statiques dans une classe en c++ ou .Net 1.1, mettre son constructeur en privé et zou

Rien ne t'empéchait de quand même mettre des champs ou méthodes non static...
L'avantage de l'utilisation d'une classe statique est que le compilateur peut vérifier qu'aucun membre d'instance n'a été ajouté par erreur. Le compilateur garantira que les instances de cette classe ne peuvent pas être créées.
De plus les classes statiques sont sealed et ne peuvent par conséquent pas être héritées (chose que tu devais spécifier de toi même avec une classe non static).

[tomlev]

c'est juste que son unique instance est créée quelque part entre le début de l'appli et le premier appel à un membre

absolument pas, aucune instance n'est jamais créée ! Ce n'est pas nécessaire, puisque toutes les méthodes sont statiques et n'ont pas le paramètre "this" (implicite dans les méthodes d'instance)

[cinemania]

Elle n'ont pas d'instance au sens propre du terme.

Une instance suppose un cadre d'objet en mémoire, avec des références nécessaires, lors de l'exécution, qui englobe tout le bloc mémoire alloué aux membres. En réalité dans une classe statique, il n'y a pas de cadre d'objet, car tu n'a pas d'instance, aucun dynamisme, pas besoin de savoir à quelle instance ni comment y accèder.
C'est le même procédé que si tu développe hors objet en C++ ou que tu fait du C, quand les membres sont alloués en mémoire, ils le sont à l'initialisation du programme dans le segment de données à une adresse fixe. (pas dans le tas)
Dans ce cas tu ne peux pas parler d'objet, d'instance, meme unique gérée par le compilateur, car tu ne sais pas non plus dans quel ordre les champs vont être réellement placé à la compilation. D'autres concepts inhérent à la représentation réelle en mémoire entres en jeux et font qu'on ne peut pas parler d'instance, mais ca devient hors sujet si on entre trop dans le détail.

C'est exactement le meme principe que les champs static d'une classe, à ceci près que là c'est pour toute la classe.

Ce concept de classe statique n'existe pas qu'en .NET (C#), et dans les langages qui l'autorise, on voie très clairement, quand on sait comment fonctionne un compilateur objet, ce qui se passe entre les classes statiques et les classes "normales", pour que ce soit du Natif.
Une des raisons des classes static de C#, provient de son héritage C++.

[tomlev]

En fait une classe statique est plus ou moins équivalente au concept de Module en VB... d'ailleurs je ne sais pas si ça existe encore en VB.NET ?

[Guulh]

absolument pas, aucune instance n'est jamais créée ! Ce n'est pas nécessaire, puisque toutes les méthodes sont statiques et n'ont pas le paramètre "this" (implicite dans les méthodes d'instance)

Disons que je me suis mal exprimé. Simplement, comme on peut accéder à ses membres comme on accèderait à par exemple MonSingleton.Instance.Membre, on peut voir ça, d'un point de vue utilisation (et non pas d'un point de vue compilo, on est d'accord ), comme une instance unique générée automatiquement.

Tournons la question de ce thread autrement : à part imposer plus de rigueur en normalisant une certaine pratique, qu'amènent les classes statiques qui ne soient pas déjà simulable en C++ / .Net 1 ? D'après la MSDN, pas grand chose :

Creating a static class is therefore much the same as creating a class that contains only static members and a private constructor. A private constructor prevents the class from being instantiated.

The advantage of using a static class is that the compiler can check to make sure that no instance members are accidentally added. The compiler will guarantee that instances of this class cannot be created.

Static classes are sealed and therefore cannot be inherited. Static classes cannot contain a constructor, although it is still possible to declare a static constructor to assign initial values or set up some static state. For more information, see Static Constructors (C# Programming Guide).

[maa]

Il me semblait avoir lu quelque part sur ce site que le concept de classe statique est propre à C#, et n'existe pas en .Net. Tel que je le comprends, elle n'a rien de virtuel : c'est juste que son unique instance est créée quelque part entre le début de l'appli et le premier appel à un membre.

Donc instance unique ou pas d'instance après compilation ?