Bonjour,
J'ai vu qu'il existait un constructeur Shared : public shared sub new ...
ce qui peut être pratique ...
j'aimerais donc savoir si existe un destructeur shared.
j'ai essaye protected overrides Shared Finalize() ==> marche pô !
Bonjour,
J'ai vu qu'il existait un constructeur Shared : public shared sub new ...
ce qui peut être pratique ...
j'aimerais donc savoir si existe un destructeur shared.
j'ai essaye protected overrides Shared Finalize() ==> marche pô !
Overrides ne peut être associer à Shared il me semble
Donc prefere un
Faudrait que tu nous precises l'interêt de cette procedure par rapport ta conception, possible que tu commettes une erreur à la base
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 Shared Sub Dispose() End Sub:
Merci pour la réponse mais je me doutais bien qu'Overrides ne veut pas dire Shared :-)
Niveau conception ?
Ben, j'ai une classe shared qui me permet de stocker des informations que je ne veux recharger 50 fois comme des pointeurs vers des fichiers.
Je veux m'assurer que les fichiers sont bien fermé et les pointeurs à null. Donc je cherche un moyen et comme il y avait un constructeur shared, je me disais qu'un constructeur shared pourrait être intéressant !
C'est quoi une classe Shared:
Pourquoi ne pas passer par une classe Singletonqui ne peut être instanciée qu'une seule fois et serait IDisposable:
![]()
+ 1Envoyé par neguib
Pardon pour le terme classe shared ... désolé ...
Pourquoi ? Pasque :-)
Je crée des singletons quand mon besoin est celui-ci : je ne veux qu'une seule instance de ma classe durant tout mon execution.
mais la, je ne veux pas d'instances du tout ... Il ne s'agit que d'une "classe" de services (ouvre un fichier, ferme un fichier) afin de les centraliser !
Je me disais : "Tiens, si il y a un destructeur shared, je pourrais pte mettre en place des contrôles ..."
Mais bon ... si c pas possible c pas grave !
Hum, des méthodes statiques pour une classe de service, jusque là, on est sur le même chemin. Par contre, il me semble que tu partes dans le fossé (promis c'est pas moi qui t'y pousse), lorsque tu parles de cosntructeur/desctructeur statiques. Il n'existe malheureusement que les constructeurs statiques qui sont appelés une fois pour initialisation soit lors d'une instanciation, soit lors de l'accès à un membre statique de la meme classe.
En ce sens, il ne s'agit pas vraiment d'un constructeur mais plutot d'une portion de code d'initialisation et en théorie, il ne faut donc pas acquérir de ressources qui n'y seraient pas libérées. Le "constructeur statique" n'est donc pas nécessaire.
Alors pourquoi vouloir detruire ce qui n'a pas été instanciéEnvoyé par maitrebn
![]()
![]()
Justement. Une classe de services/classe utilitaire n'est pas censée avoir d'état. Uniquement des méthodes statiques, pas de champs. Donc rien à détruire :)Envoyé par maitrebn
Moralité, pour la piste du problème de conception, regarde du côté de ce que tu as besoin de détruire. Il n'y aurait pas un autre endroit où caser ça, pour ne laisser que les méthodes dans la classe ?
(en général, c'est une responsabilité qui retombe sur les clients de la classe eux-mêmes. au pire sur un singleton)
Comme je disais (niveau conception), je me demandais juste tiens "il y a un initialisateur statique" pkoi pas l'inverse !
Je suis bien d'accord que je n'ai rien à libérer (d'ailleurs je n'ai rien à libérer :-) mais je m'en serais servis pour controler que toutes les connexions qui m'ont été demandées ont bien été fermées ... (par exemple !!!!)
C'est tout !
Voilà !
Partager