Module via Mémoire suite..

J'vais essayer de reprendre tout ca ... je sais pas si c'est vraiment ce que
voulais dire Zoury.

Les modules proviennent du VB6 et ne sont pas vraiment Orienté Objet (OO)
dans le sens ou en objet le point de départ est la classe. En fait un module
revient a faire une classe scélée dont tous les membres sont statiques et qui
ne peut pas être instanciée.

Voici un exemple avec un module et ce même module transformer en classe.

Module Module1

Dim myVar As String = "Toto"

Public Function Hello() As String
Return "Hello World"
End Function
End Module

Console.Write (Hello)

Public NotInheritable Class Module1
Private Sub New()
End Sub

Public Shared myVar As String = "Toto"

Public Shared Function Hello() As String
Return "Hello World"
End Function
End Class

Je te conseille de plutot privilégié les classes que les modules afin de
rester cohérent avec la conception orientée objet.

Pour gérer au mieux l'espace mémoire occupé par tes modules, je te conseille
de découper ton application en composants, c'est a dire en librairies de
classes, et faire en sorte qu'une librairie soit consacrée à une
fonctionnalité (Securité, Impression ...) ... de cette manière, si tout est
bien concue tu pourras meme réutiliser ses composants dans d'autres
applications.

Maintenant, et si mes souvenirs sont bons, lors de l'exécution d'une
assembly, la CLR ne chargent pas toutes les assembly référencées en mémoire
et donc en découpant bien ton application tu peux faire en sorte que tous les
composants ne soit pas chargé dès que l'application est exécutée.

De toute manière, la charge mémoire des postes utilisateurs ne devrait pas
influencer sur les performance de l'application, sauf si bien sur l'espace
mémoire est insuffisant.

Voila :D

"Annie L." wrote:

Si je crée 3 modules (de procédures et fonctions utilisés régulièrement dans
mon projet et déclaration de variables
> globales 'Public'), est ce qu'il charge ces modules dans la mémoire au démarrage de mon projet?
>
> Si un module n'est appelé que très rarement, va-t-il le charger en mémoire seulement lorsque j'appelle une procédure
ou fonction de ce module?
>
> Ce que je veux dans tout ceci, c'est de libérer la mémoire au maximum et faire que mon programme soit beaucoup plus
> rapide à l'exécution pour les utilisateurs.

Zoury a écrit :

Aussi note que les éléments shared sont conservés en mémoire jusqu'à la fin
de l'application.

Il serait donc bien de regroupés tes méthodes par catégories (Security,
Impression, etc..) dans modules distincts.
Aussi afin de ne pas trop abuser de l'emploi des modules,
une approche OO est recommandée.

QUELLE SORTE D'APPROCHE 'OO' DOIS-JE EMPLOYER POUR ÉVITER DE L'EMPLOI
ABUSIFS DES MODULES?
J'AIMERAIS AVOIR UN EXEMPLE!

>
> Toutes les suggestions sont les bienvenues, Merci!
>