Discussion :

[JOHN14]

Bonjour à tous.

Je fais actuellement de la maintenance applicative et je suis troublé par ce que je découvre :

Des méthodes publiques Property Get, Let et Set sont définit en dehors des modules de classe.

Exemples :

Code :

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

1
2
3
4
5
Public Property Set MyNames(ByRef name As String, ByVal cells As Range)
On Error Resume Next
    Call MyName(name).Delete
    Call ThisWorkbook.Names.Add(name, cells)
End Property

ou

Code :

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

1
2
3
4
5
Public Property Get MyName(ByRef name As String) As name
Set MyName = Nothing
On Error Resume Next
Set MyName = ThisWorkbook.Names(name)
End Property

ou

Code :

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

1
2
3
Public Property Let MaVersion(ByRef value As String)
MyValues("_MaVersion") = value
End Property

- Est-ce du "code Sale" ou est-ce que cela a un rôle particulier ?

- Ne peut-on pas tout simplement remplacer ces propriétés par de fonction ou des procédures ?

Merci de votre attention.

[vinc_bilb]

Bonjour,

Vous pouvez jetter un oeil à ce poste; https://www.developpez.net/forums/d1...y-get-set-let/

[JOHN14]

Je connais ce lien mais la réponse n'est pas dedans .

Bonjour,

Vous pouvez jetter un oeil à ce poste; https://www.developpez.net/forums/d1...y-get-set-let/

Cordialement.

[NVCfrm]

C'est une façon de déclarer des variables publiques accessibles n'importe ou.
Cela se fait généralement quand on veut définir une variable publique, en lecture pour les autres programmes.

[JOHN14]

Merci NVCfrm pour ton intérêt.

Peux-tu développer ta réponse ?

C'est une façon de déclarer des variables publiques accessibles n'importe ou.
Cela se fait généralement quand on veut définir une variable publique, en lecture pour les autres programmes.

Dans l'exemple que j'ai donné, il n'y a pas de une variable publique dans les modules de ces methode. Les méthodes citées ne font référence qu'à des plages nommées du classeur.

Quels autres programmes sont en possibilités de lire le contenu de variables d'un programme EXCEL ?

Cordialement.

[NVCfrm]

Dans l'esprit de la programmation tout objet, ton module standard est lui aussi accessible comme un objet, avec des méthodes et des propriétés. Mais il faudrait nuancer, le module standard n'implemente pas les possibilites d'un module de classe.

En fait une déclaration Property peut se déclarer dans n'importe quel module de code.
Les suffixes Get et Set peuvent se comprendre simplement comme ceci : Get renvoi une valeur, Set definit une valeur.

La declaration Public Property [Get|Let|Set] (Public est optionnel, c'est la valeur par defaut) rend la valeur ou la définition réalisé dans ses procédures Property accessible sur tout le projet.

Il est recommandé d'utiliser ces procédures a la place de variables publiques pour mieux contrôler leur assignation ou accessibilité. Ce qui peut eviter pas mal de bugs quand on a beaucoup de code un peu partout qui accèdent a la meme variable.

Comme l'objet Range par exemple qui est defini en tant qu'une variable globale, accessible entre tous les projets ouverts de l'instance en cours, l'application Excel a besoin de réglementer la définition de certaines choses de celui-ci. La variable Range(A1) est manipulée ou affectée via des propriétés dont le fonctionnement est transparent pour l'utilisateur vba.

Parfois l'utilisateur VBA peut vouloir developper un prog avec les mêmes impératifs que Range.

Au fond tout est variable.

Et pour terminer un exemple basic dans un nouveu module standard places ce code

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Option Explicit
'Option Private Module
Private rw_val As Long
 
Property Let MyReadWriteVar(valeur As Long)
    rw_val = valeur
End Property
 
Property Get MyReadWriteVar() As Long
    Dim myLocalVar As Long
    MyReadWriteVar = rw_val
End Property
 
Static Property Get MyRangeOffset(cible As Range)
    Dim myref As Range
    If myref Is Nothing Then Set myref = Range("b20")
 
    MyRangeOffset = cible.AddressLocal(True, True, xlR1C1, , myref)
End Property

Sur un autre module quelconque

Code :

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

1
2
3
4
5
6
7
8
Sub testProp()
    Dim unVar
    unVar = MyRangeOffset(Range("c5"))
    unVar = MyReadOnlyVar ' good
    MyReadWriteVar = 105 'good
    unVar = MyReadWriteVar 'good
    MyReadOnlyVar = unVar 'Bad .Nous n'avons pas prévu l'affectation de celle ci. On ne peut qu'obtenir sa valeur
End Sub

pas a pas avec F8.

[JOHN14]

Merci beaucoup.

C'est maintenant beaucoup plus claire pour moi.

Bien cordialement.

[Pierre Fauconnier]

Salut.

Dans l'esprit de la programmation tout objet, ton module standard est lui aussi accessible comme un objet, avec des méthodes et des propriétés.[...]

Sauf qu'un module standard n'est pas instanciable, la notion de méthode et de propriété ne s'appliquant dès lors pas à ce type de module, selon moi. Un module standard n'a pas de "propriété" au sens donné à cela en POO.

Dès lors, il faudrait réserver les property à des modules de classe, puisque cela permet de définir ou de lire une propriété (... d'un objet). La notion de propriété dans un module standard n'a guère de sens, pas plus que les variables privées de module standard, d'ailleurs. Dans une optique POO, il faut considérer le module standard comme une classe statique (si on compare à C#, par exemple), donc non instanciable et dépourvue de "méthodes" et de "propriétés", les méthodes étant les actions réalisables avec/sur l'objet et les propriétés permettant de définir l'objet. Pas d'objet (instancié), donc pas de méthodes et pas de propriétés... ^^

Dans un module standard, je privilégierais function en utilisant le moins possible les variables globales ou publiques, de manière à obtenir le couplage le plus faible possible (la dépendance la plus faible possible de la fonction au reste du code). Pour les modules de classe, j'utilise fréquemment la variable "public..." qui est en fait une propriété auto-implémentée lorsque l'objet ne doit pas la transformer, sinon, je passe par une variable privée et le jeu Property Let/Property Get lorsqu'il y a transformation entre l'affectaction et la restitution. Il faut noter au passage qu'on parle abusivement de "variable publique" dans un module de classe lorsque l'on utilise Public MaVariable As... alors qu'en fait, c'est une propriété auto-implémentée en lecture/écriture.

[...]

- Est-ce du "code Sale" ou est-ce que cela a un rôle particulier ?

- Ne peut-on pas tout simplement remplacer ces propriétés par de fonction ou des procédures ?
[...]

Pour moi, oui, c'est du code sale

[NVCfrm]

...
Sauf qu'un module standard n'est pas instanciable, la notion de méthode et de propriété ne s'appliquant dès lors pas à ce type de module, selon moi. Un module standard n'a pas de "propriété" au sens donné à cela en POO.

Si l'intention de cette remarque est de clarifier le passage omis dans le morceau du paragraphe cité, je passes.

Dans l'esprit de la programmation tout objet, ton module standard est lui aussi accessible comme un objet, avec des méthodes et des propriétés. Mais il faudrait nuancer, le module standard n’implémente pas les possibilités d'un module de classe.

En PoO tout est objet je te le rappelle.
Je te rappelle également que toutes les procédures ou fonctions sont des méthodes.
Dans l'angle du VBA pur, chaque module quelque soit le type est un objet.

Code :

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

1
2
Public varX ' dans un module standard nomme nonClasseModule
l'appel de varX equivaut en réalité à nonClasseModule.varX

Parfois on peut avoir besoin d'une variable disponible pour plusieurs routines situés n'importe où dans le projet. Souhaiter qu'elle ne soit defini hors d'un certain cadre de verification de contrôles. Les Procedures Property servent justement à cela rien de plus; que ce soit dans un module de classe ou standard, la déclaration Property vise une intention de contrôle d'affectation ou d'accès à la valeur par des préalables. Donc on peut le mettre dans le module standard, en évitant aux autres d'instancier une classe pour ça.

La distinction d'un module de classe est qu'il renvoi un objet, donc qu'il peut être instancié comme tu l'as souligné.
D'ailleurs je ne vois pas trop le but de ta remarque. Ne seriez vous pas d'accord avec le fait qu'on peut le considérer comme un objet ?

[Invité]

Bonsoir,

Une propriété n'a pas d'autre objet que de qualifié le données fourni à la variable module d classe ou module standard.

Utiliser une propriété comme passe plat à une variable dans un module de classe ne présente aucun intérêt autant déclarer sa variable en public.

Déclarer que définir des propriétés dans un module standard comme un "code sale" est une aberration.

Un module standard n'est rien d'autre qu'un module de classe à instanciation implicite Freind.
En C# on préfèrera les déclarer en static!

Code Sale :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
  Const DATAOBJECT_BINDING As String = "new:{1C3B4210-F441-11CE-B9EA-00AA006B1A69}"
Public Property Let PressePapier(Value)
    With CreateObject(DATAOBJECT_BINDING)
        .SetText Value
        .PutInClipboard
    End With
End Property
Public Property Get PressePapier()
    With CreateObject(DATAOBJECT_BINDING)
        .GetFromClipboard 
        PressePapier = .GetText
    End With
End Property

[Pierre Fauconnier]

[...]
Une propriété n'a pas d'autre objet que de qualifié le données fourni à la variable module d classe ou module standard.[...]

Je suis d'accord sur le principe, c'est sur le concept que je tique. Ca me semble étrange de qualifier un module standard. Les propriétés (Property Get/Let) sont apparues avec la POO pour qualifier un objet. Or, un module standard, même si c'est un "objet", n'est pas instanciable, et il est donc pour moi aberrant de vouloir le qualifier. Il y a d'autres écritures pour arriver au même résultat, mais qui me semblent mieux coller à un "objet" que l'on ne peut instancier, même si on veut protéger les données passées à cet "objet". Je ne vois pas en quelle occasion il est intéressant de passer par des Property dans des modules standard et je gage qu'il est toujours possible de se passer des Property dans ce type de modules. Je n'ai jamais vu de code d'un module standard qui nécessitait l'emploi des Property.

[...]
Utiliser une propriété comme passe plat à une variable dans un module de classe ne présente aucun intérêt autant déclarer sa variable en public.[...]

Je n'ai rien dit d'autre en parlant de propriétés auto-implémentées. J'ai simplement précisé que c'est un abus de langage de parler de variable publique pour un objet, car déclarer une variable Public x as ... dans un module de classe (un "vrai" qui doit être instancié) n'en fait pas une variable publique, mais bien une propriété auto-implémentée.

[...]
Déclarer que définir des propriétés dans un module standard comme un "code sale" est une aberration.[...]

Il n'y a pas qu'une vérité en informatique, que ce soit la tienne ou la mienne. Je maintiens que, conceptuellement, c'est pour moi sale de coder des propriétés dans un module standard, parce que cela dénature le concept de propriété et qu'il y a moyen très facilement de procéder autrement dans un module standard.

[...]
Un module standard n'est rien d'autre qu'un module de classe à instanciation implicite Freind.

A mes yeux, Friend n'a pas grand chose à voir avec un module standard, je pense. Friend est plus un concept d'héritage et il n'y a pas d'héritage en VBA. Pour moi, un module standard est en fait une classe Static (comme je l'ai dit dans mon premier message) => non instanciable.


Après, ce sera au lecteur de se faire sa propre opinion et de trouver son style d'écriture

[Pierre Fauconnier]

[...]En PoO tout est objet je te le rappelle.[...]

Je pense que l'on ne peut pas qualifier le VBA de vrai langage POO. Il manque l'héritage (et donc la notion de friend dont parle Robert, notamment) même si dans les faits et vu les projets VBA habituellement créés, l'absence de l'héritage dans les classes perso n'est pas vraiment gênante, mais également la notion de constructeur (Initialize étant un constructeur imposé auquel on ne sait pas passer d'arguments), ce qui est à mon avis beaucoup plus gênant.

Et je rappelle je n'ai rien contre le fait qu'on appelle un module standard un objet (ou plutôt une classe), je dis simplement que cette classe est non instanciable, et que cela n'a donc pas beaucoup de sens de vouloir attribuer des propriétés (notion POO) à un "objet" qui dans la pratique n'en est pas un, puisque l'on ne sait pas le créer.

[...]Je te rappelle également que toutes les procédures ou fonctions sont des méthodes.[...]

Ca, c'est toi qui le dis et qui le vois comme cela. C'est ta vérité mais ce n'est pas la mienne, comme je l'ai expliqué précédemment . Une méthode est liée à un objet instancié, une procédure/fonction étant liée à une classe statique. Si l'on voulait pousser ton raisonnement plus loin, on ne ferait même pas la différenciation entre procédure et fonction, une procédure n'étant en fait qu'une fonction Void. La procédure (Sub) est une notion typiquement VBA (et vb.net), mais n'existe pas dans la plupart des autres langages. Mais si tu as envie d'appeler une procédure une méthode, c'est ton choix. C'est pour moi une utilisation impropre (donc sale ) du vocabulaire VBA.

[...]Dans l'angle du VBA pur, chaque module quelque soit le type est un objet.[...]

Je ne sais pas ce que ça veut dire "dans l'angle du VBA pur"... En fait, "VBA pur", ça ne veut rien dire pour moi . Mais comme déjà précisé, le fait que l'on considère un module standard comme un objet (ou plutôt une classe) ne me gêne pas. Ce qui me gêne, c'est que l'on attribue des propriétés (notions POO) à un "objet" qui, dans les faits, n'est pas manipulable comme un objet. C'est pour moi dénaturer la notion de propriété qui, par définition, est valorisée pour un objet instancié d'une classe pour le différencier d'un autre objet de la même classe. Comme il ne peut y avoir plusieurs objets issus de la même "classe" qu'un module standard particulier (on ne peut pas écrire set obj = new Module1^*), cette notion de propriété n'a pour moi pas de sens sur un module standard. Mon propos se situe uniquement à ce niveau-là.

Code :

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

1
2
Public varX ' dans un module standard nomme nonClasseModule
l'appel de varX equivaut en réalité à nonClasseModule.varX

Pas toujours. Ce n'est vrai que si tu as Public VarX que dans un seul module standard. Si tu as cette ligne dans d'autres modules standards, tu ne pourras pas appeler simplement varX et tu devras la préfixer du nom du module. Mais c'est pour moi une mauvaise façon de coder. Si tu souhaites prouver par ce code qu'un module standard est un objet (ou plutôt une classe non instanciable), je l'admets sans soucis. C'est clair que en POO, une classe statique est une classe, mais ce n'est pas pour cela qu'il est judicieux d'utiliser des méthodes et des propriétés pour cette classe.

[...]
Parfois on peut avoir besoin d'une variable disponible pour plusieurs routines situés n'importe où dans le projet. Souhaiter qu'elle ne soit defini hors d'un certain cadre de verification de contrôles. Les Procedures Property servent justement à cela rien de plus[...]

Je n'ai pas dit qu'il ne fallait pas utiliser des variables globales (publiques dans un module standard), j'ai dit qu'il fallait les limiter au strict nécessaire car elles créent un couplage fort (une dépendance forte) entre les procédures/fonctions/méthodes/propriétés qui les utilisent et le reste du code, réduisant ou empêchant la réutilisation du code. Quant à limiter leur définition, il n'est pas nécessaire de passer par des Property pour limiter la valorisation d'une variable à certaines parties du code. Il existe des mécanismes qui permettent cela facilement au sein de modules standard. Et j'aouterai qu'il ne faut jamais appeler une variable globale (une variable publique d'un module standard) dans un module de classe, car cela casse la notion d'encapsulation qui devrait prévaloir pour le module de classe.

[...]
La distinction d'un module de classe est qu'il renvoi un objet, donc qu'il peut être instancié comme tu l'as souligné.
D'ailleurs je ne vois pas trop le but de ta remarque. Ne seriez vous pas d'accord avec le fait qu'on peut le considérer comme un objet ?

Dans les faits, non. Un module standard n'est pour moi pas à considérer comme un objet, mais comme une bibliothèque de code.

Là-dessus, comme déjà dit plus haut, chacun son avis et le lecteur se forgera sa propre opinion. J'en resterai là dans cette discussion



^* Sauf, évidemment, à créer un nouveau module de classe et à l'appeler Module1

[NVCfrm]

Bonjour,

Et je rappelle je n'ai rien contre le fait qu'on appelle un module standard un objet (ou plutôt une classe), je dis simplement que cette classe est non instanciable

Bah, si tu donnes cette précision, on passe alors.

Je suppose pour le reste que ce sont tes opinions, dont certains côtes méritent une révision de points de vue entre autres l'écriture de la déclaration Private unVar a tout son sens. C'est pour la lisibilité. Mais surtout ça colle avec la gestion interne du compilateur vba qui classe par défaut la déclaration Dim unVar dans la catégorie des Private Vars.

Et pour ne pas perdre du temps dans un débat improductif, afin d’éclaircir ta vision sur la faisabilité, ou le côte sain ou non des déclarations Property's dans un module standard. Je signale qu'il y a un certain nombre de "fonctions/instructions" de vba qui sont en fait des declarations property et non function qui sont dans les modules standard du projet VBA. Par ex: Timer est une property en lecture seule, au contraire de Time, je m'en rappelle tres bien pour avoir un jour perdu du temps sur un bug ou j'avais commis l'erreur d'ajouter un 'r' au Time que je manipulais. Il ya un jeu de Property's dans un module standard precis du vba que je t'invite a vérifier via l'explorateur de projet.

C'est finalement un peu agaçant toute cette ritournelle, sur la POO; les modules de classe/standard.
VBA est orienté objet, point final, tu l'admets déjà.
Pour quelqu'un qui voudrait outrepasser les limitations de VBA sur les classes d'objet il 'y a d'autres langages pour ça. Mais cela n'enlève pas le fait que c'est un langage orienté objet.


Il semble, je n'en suis pas sûr encore, mais vu le décorticage maladroit de mes propos, que l'objectif de ton intervention n'est pas d'apporter une certaine lumière dans la discussion.

[Pierre Fauconnier]

[...]
Il semble, je n'en suis pas sûr encore, mais vu le décorticage maladroit de mes propos, que l'objectif de ton intervention n'est pas d'apporter une certaine lumière dans la discussion.

Il y a décidément des personnes avec lesquelles il est apparemment impossible de débattre sereinement sur un plan technique et qui se sentent attaquées personnellement dès que l'on émet un avis technique différent du leur. J'en resterai là, mais je n'en penses pas moins! Cela dit, ne te connaissant pas, je n'ai a priori rien contre toi, il est donc ridicule de me prêter des intentions inamicales à ton endroit.



Mais puisque tu m'invites à regarder l'explorateur d'objets, je t'invite également à le regarder et à observer, justement, les différences entre Time (propriété en lecture/écriture de type variant du module standard DateTime) et Timer (propriété en lecture seule de type Single du même module standard). Puisque tu sembles prendre cet exemple pour démontrer le bienfondé de l'utilisation des Property dans un module standard, je t'invite à essayer de modifier la propriété Time. Tu vas normalement te prendre une erreur 70 dans les dents. Alors, logique et bien écrit, le module DateTime? Perso, je persiste à dire que ce n'est pas logique d'avoir des propriétés en lieu et place de fonctions, dans ce cas-là notamment.

Le fait que les concepteurs du VBA aient codé de cette façon n'est pas pour moi une justification suffisante que c'est une bonne chose de coder ainsi. Ils ont aussi permis que l'on ne déclare pas ses variables, ce n'est pas pour cela que l'on peut soutenir qu'il est bon de ne pas déclarer ses variables... Le VBA permet plein d'autres choses que personnellement je désapprouve. Ce n'est pas parce que ces techniques sont permises que l'on doit obligatoirement trouver chouette de les utiliser

Et encore une fois, Ousmane, bien lire ma signature avant de prêter des intentions qui ne sont pas miennes.

[mromain]

Bonjour à tous,

Discussion très intéressante !

Je suis dans l’ensemble plutôt d’accord avec Pierre.
Personnellement, je banni les variables globales. Utiliser les propriétés (publiques) pour accéder dans tout le projet à une variable (un peu moins globale) ne résout pas le problème de fond de "pourquoi on a besoin de cette variable".

Les cas où je m’autorise à utiliser une propriété dans un simple module sont rares. Ils consistent à "fournir des objets externes".
Par exemple, j’utilise régulièrement le FileSystemObject dans mes projets.
Plutôt que de déclarer une variable FSO, l’instancier et la détruire dans chaque procédure où j’en aurai besoin, je préfère ajouter la propriété suivante dans un module :

Code :

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

1
2
3
4
5
Public Property Get FSO() As Object 'Scripting.FileSystemObject
Static s_o_fso As Object
    If s_o_fso Is Nothing Then Set s_o_fso = CreateObject("Scripting.FileSystemObject")
    Set FSO = s_o_fso
End Property

Ainsi, dès que j’ai besoin du FSO dans mon projet, il me suffit d’écrire FSO pour l’obtenir.

Si la référence Microsoft Scripting Runtime est cochée, il me suffit de modifier la signature de la propriété pour bénéficier de l’intellisense.

Pour l’exemple de dysorthographie sur le DataObject, je prévère accéder directement à l’objet lui-même ainsi :

Code :

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

1
2
3
4
5
Public Property Get DataObj() As Object 'MSForms.DataObject
Static s_o_dObj As Object
    If s_o_dObj Is Nothing Then Set s_o_dObj = CreateObject("new:{1C3B4210-F441-11CE-B9EA-00AA006B1A69}")
    Set DataObj = s_o_dObj
End Property

Et manipuler ses propriétés SetText, PutInClipboard, … dans le "code métier"

Après, tout est une question de point de vue et d'habitudes...
Encore une fois : discussion très intéressante, au plaisir de lire la suite

A+

[Pierre Fauconnier]

Salut MRomain,

Je fais presque la même chose...

Code :

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

1
2
3
4
5
Public Function FSO() As Object 'Scripting.FileSystemObject
Static s_o_fso As Object
    If s_o_fso Is Nothing Then Set s_o_fso = CreateObject("Scripting.FileSystemObject")
    Set FSO = s_o_fso
End Function

Ca s'utilise de la même manière dans la suite du code

[Pierre Fauconnier]

Voilà le code d'un module standard Module1 qui "singe" un peu les différences entre Time et Timer.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Function getFirstName() As String
  getFirstName = "Pierre"
End Function
 
Property Get FirstName() As String
  FirstName = "Pierre"
End Property
 
Property Get LastName() As String
  LastName = "Dupont"
End Property
 
Property Let LastName(Value As String)
  Err.Raise 70
End Property

l'explorateur d'objet va nous apprendre que:

• getFirstName est une fonction de la classe Module1;
• FirstName est une propriété en lecture seule de la classe Module1;
• LastName est une propriété en lecture/écriture de la classe Module1.

Néanmoins, une tentative d'écriture de LastName renverra l'erreur 70 (comme si on essaie de modifier DateTime.Time). Donc, on a une propriété en lecture/écriture qui est en fait... en lecture seule . On voit donc bien que, pour un même résultat, il y a plusieurs possibilités, et que chacun choisira celle qui lui convient le mieux. Je pense simplement qu'il n'est pas innocent d'utiliser une syntaxe plutôt qu'une autre et je préfère pour ma part la clarté à la confusion, en estimant que c'est un style confus d'utiliser Property dans un module standard (Ca n'engage que moi).

Personnellement, s'agissant d'une classe statique (un module standard), je préfère Function aux autres solutions. Mais soyons clairs que c'est juste une question de goût.

@Ousmane: Du coup, tu verras que je suis bien d'accord pour dire que les modules standards sont des classes

[NVCfrm]

Il y a décidément des personnes avec lesquelles il est apparemment impossible de débattre sereinement sur un plan technique et qui se sentent attaquées personnellement dès que l'on émet un avis technique différent du leur. J'en resterai là, mais je n'en penses pas moins! Cela dit, ne te connaissant pas, je n'ai [I]a pri

Comment percevoir autrement tes remarques, quand je suis cité à tout bout de champ pour développer une façon de voir avec une connotation qui supposerait que j'ai dit du n'importe quoi, .

Par exemple :

Sauf qu'un module standard n'est pas instanciable, la notion de méthode et de propriété ne s'appliquant dès lors pas à ce type de module, selon moi. Un module standard n'a pas de "propriété" au sens donné à cela en POO.
Dès lors, il faudrait réserver les property à des modules de classe

Au final on n'en est ou dans l'evolution des eclaircissements que tu donnes ?
Encore ici
[quote = Pierre]

Code :

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

1
2
3
Public varX ' dans un module standard nomme nonClasseModule
l'appel de varX equivaut en réalité à nonClasseModule.varX

Pas toujours. Ce n'est vrai que si tu as Public VarX que dans un seul module standard. Si tu as cette ligne dans d'autres modules standards, tu ne pourras pas appeler simplement varX et tu devras la préfixer du nom du module. Mais c'est pour moi une mauvaise façon de coder. Si tu souhaites prouver par ce code qu'un module standard est un objet (ou plutôt une classe non instanciable), je l'admets sans soucis. C'est clair que en POO, une classe statique est une classe, mais ce n'est pas pour cela qu'il est judicieux d'utiliser des méthodes et des propriétés pour cette classe.[/quote]
En soulignant cet aspect, qu'est ce que tu veux montrer au fait dans cette replique ? Rappeler les regles de priorite dans l'appel d'une variable dont le nom existe en deux endroits ? Chose dont je ne parles pas, si le but est de contredire, je ne vois pas non plus dans cette réaction ce qui contredit l'intention du propos qui doit rester relatif au contexte.

Et encore

[...]
Parfois on peut avoir besoin d'une variable disponible pour plusieurs routines situés n'importe où dans le projet. Souhaiter qu'elle ne soit defini hors d'un certain cadre de verification de contrôles. Les Procedures Property servent justement à cela rien de plus[...]

Je n'ai pas dit qu'il ne fallait pas utiliser des variables globales (publiques dans un module standard), j'ai dit qu'il fallait les limiter au strict nécessaire car elles créent un couplage fort (une dépendance forte) entre les procédures/fonctions/méthodes/propriétés qui les utilisent et le reste du code, réduisant ou empêchant la réutilisation du code. Quant à limiter leur définition, il n'est pas nécessaire de passer par des Property pour limiter la valorisation d'une variable à certaines parties du code. Il existe des mécanismes qui permettent cela facilement au sein de modules standard. Et j'aouterai qu'il ne faut jamais appeler une variable globale (une variable publique d'un module standard) dans un module de classe, car cela casse la notion d'encapsulation qui devrait prévaloir pour le module de classe.

Mais qui a de nous a dit ici sur ce sujet qu'il faut ou pas utiliser de variable publique ou globale ? Qui de nous cherche a justifier leur utilisation ou non. Je cherche a te faire comprendre desesperement l'interet des procedures Property. Et enfin de phrase tu justifies l'usage de property dans un module standars sans t'en apercevoir.

Encore ... quoi que j'estime que tu n'as pas compris l'exemple du Time ou du Timer.

J'ai centré ma réponse au demandeur sur la question posée qui me semble du genre : Est ce normal de trouver des déclarations Property dans un module standard. A cette question la réponse est bien évidemment OUI. Il a voulu des éclaircissements, je me suis donne comme objectif de le lui faire comprendre en peu de mots et non de faire un livre qui détaille tous les concepts sous-jacents vu son niveau.
On en reste la.
Désolé, ce n'est pas ici que tu sortiras une connerie de mon intervention (c'est bien le but non avoué bien que tu t'en gardes).

[NVCfrm]

Voilà le code d'un module standard Module1 qui "singe" un peu les différences entre Time et Timer.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Function getFirstName() As String
  getFirstName = "Pierre"
End Function
 
Property Get FirstName() As String
  FirstName = "Pierre"
End Property
 
Property Get LastName() As String
  LastName = "Dupont"
End Property
 
Property Let LastName(Value As String)
  Err.Raise 70
End Property

l'explorateur d'objet va nous apprendre que:

• getFirstName est une fonction de la classe Module1;
• FirstName est une propriété en lecture seule de la classe Module1;
• LastName est une propriété en lecture/écriture de la classe Module1.

Néanmoins, une tentative d'écriture de LastName renverra l'erreur 70 (comme si on essaie de modifier DateTime.Time). Donc, on a une propriété en lecture/écriture qui est en fait... en lecture seule

Jusque la tu n'as pas compris le fonds. Les property servent a des préalables dans l'accès, avec des impératifs propre aux objectifs de développement. C'est comme disposer une variable chaîne publique censée contenir une date que d'autres codes dans des routines situées n'importe ou peuvent lire ou renseigner. Et c'est la que l'on souhaiterait a l'instar des sous routines Function ou Sub, que la chose soit manipulee comme si c’était une variable pour ne pas recevoir n'importe quelle chaîne incompatible, ou pour une actualisation de l'information a renvoyer censée contenir la date.

Sur ce bonne continuation.

[Pierre Fauconnier]

Ok.

Donc, quand on n'est pas d'accord avec une technique que tu prônes, c'est qu'on est trop con pour comprendre... Ben dis donc!

J'ai parfaitement compris. Je ne suis simplement pas d'accord avec l'écriture que tu proposes.