XL 2013 VBA classes / sub ou Property

agourn

XLDnaute Junior
Bonjour à tous,
j'ai une application dans laquelle j'ai décidé d'utiliser des classes car plus adaptées en termes de données et d'organisation du code. Et surtout plus sympas, vous serez d'accord !
La question générale que je me pose est : est-ce réaliste de vouloir presque tout faire avec des Property Let/Get ou il faut de toute façon mélanger avec des méthodes Sub ou Function ? on peut bien entendu carrément ne faire que des Sub/Function et ça marche mais dans ce cas, o perd l'avantage des classes.
Exemple concret :
J'ai une classe d'un assemblage
VB:
clsAssemblage

Public X as Double

Public Y as Double

'ensuite besoin de calculer 3 paramètres : x1, x2 et x3 dépendant de X et Y.

' Méthode 1 :

public sub (x1, x2, x3)

x1=formule

x2 = formule

'etc, en fonction de X,Y.

end sub



' Méthode 2 : avec des Property, j'imagine une Property pour chaque paramètre à calculer.
qu'en pensez-vous ?
merci
agourn
 
Solution
VBA parle de Property quand c'est écrit sous la forme d'une procédure Property, tout simplement.
Une telle procédure n'est pas forcément en soit une propriété. D'ailleurs on peut en écrire aussi dans un module standard. On conviendra qu'une propriété ne se spécifie pas, à l'utilisation, avec des paramètres, sinon c'est plutôt une méthode, puisqu'elle ne dépend pas que de l'état de l'objet.

Dranreb

XLDnaute Barbatruc
Disons que je considère une Property Get munie d'un ou plusieurs paramètres comme une méthode et non comme une propriété. Pareil pour une Property Let ou Set qui a des argument supplémentaires devant le dernier indiquant ce qu'il faut attribuer, spécifié, à l'utilisation, après le signe '=' de l'affectation.
Par ailleurs pour une propriété en lecture seule j'utilise en général une Function sans paramètre plutôt qu'une Property Get.
 

dysorthographie

XLDnaute Accro
Bonjour,
Je suis pas certaine d'avoir le niveau pour comprendre le débat qui est en train de s'installer !

On utilise pas un module de classe pour le fun mais pour sa puissance!

Un module de classe impose une autre façon de raisonner.

Une propriété avec paramètres n'est pas une méthode car les méthodes ne sont pas en lecture/écrire !

Dans la classe clsAssemblage on trouve des variables public mais que ce passe-t-il si nous leurs fournissons du texte ?
Il y aura inévitablement un message d'erreur !
Si nous définissons ces variabled comme privé et que nous déclarons des propriétés nous pourrions vérifier que les valleyur passées sont bien des double ?

Idem pour un tableau mais il faut concentir des propriétés avec paramètres.

Je me demande ce agourn attend de cette discussion.
 
Dernière édition:

Dranreb

XLDnaute Barbatruc
1603065914556.png
 

Dranreb

XLDnaute Barbatruc
Je ne contestai pas que Range était aussi une classe. Oui Range est aussi une méthode de Range. Elle est très peu utilisée. En fait beaucoup de propriété et méthodes de Worksheet en sont aussi de Range. Range quant à lui est aussi une propriété, cette fois, des objets ListObject, ListRow et ListColumn. Beaucoup de propriétés et de mèthodes d'Excel ont comme nom celui de leur type.
 

Dranreb

XLDnaute Barbatruc
VBA parle de Property quand c'est écrit sous la forme d'une procédure Property, tout simplement.
Une telle procédure n'est pas forcément en soit une propriété. D'ailleurs on peut en écrire aussi dans un module standard. On conviendra qu'une propriété ne se spécifie pas, à l'utilisation, avec des paramètres, sinon c'est plutôt une méthode, puisqu'elle ne dépend pas que de l'état de l'objet.
 

Discussions similaires

Réponses
1
Affichages
119
Réponses
0
Affichages
83

Statistiques des forums

Discussions
311 725
Messages
2 081 941
Membres
101 846
dernier inscrit
Silhabib