Discussion :

[dahtah]

Bonjour à tous,
Beaucoup d'applications nécessitent des compteurs.
Comment les utilisez-vous? Pour ma part ils sont tout le temps statique (c'est là peut-être mon problème), car ils s'appliquent à n'importe quel objet.
De plus vaut-il mieux faire

Code :

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

1
2
3
4
5
6
7
8
incrementerObjetA(){
    compteurObjetA ++; 
    ...
}
incrementerObjetB() {
    compteurObjetB ++; 
    ...
}

ou alors

Code :

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

1
2
3
4
5
6
7
8
9
10
incrementerObjet(Objet objet) {
    switch (objet) {
        case objetA :
            compteurObjetA ++;
            ...
        case objetB :
            compteurObjetB ++;
            ...
    }
}

Ces bouts de code sont juste à titre d'exemple.
En espérant avoir vos avis et vos méthodes...

[PRomu@ld]

Le premier exemple est préférable puisqu'il facilite la conception objet. Dans le deuxième cas, ça nécessite à la classe mère de connaître ses fils, ce qui n'est pas hyper logique.

[paradize3]

Bonjour à tous,
Beaucoup d'applications nécessitent des compteurs.
Comment les utilisez-vous? Pour ma part ils sont tout le temps statique (c'est là peut-être mon problème), car ils s'appliquent à n'importe quel objet.
De plus vaut-il mieux faire

Code :

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

1
2
3
4
5
6
7
8
incrementerObjetA(){
    compteurObjetA ++; 
    ...
}
incrementerObjetB() {
    compteurObjetB ++; 
    ...
}

ou alors

Code :

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

1
2
3
4
5
6
7
8
9
10
incrementerObjet(Objet objet) {
    switch (objet) {
        case objetA :
            compteurObjetA ++;
            ...
        case objetB :
            compteurObjetB ++;
            ...
    }
}

Ces bouts de code sont juste à titre d'exemple.
En espérant avoir vos avis et vos méthodes...

perso, j'ecrirais plutot une qqch genre (pseudo-code conceptuel).

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
20
21
 
interface ICompteur {
    vritual void increment();
};
 
class A extends ICompteur { 
   static int counter = 0;
   override increment() {counter ++}...
};
class B extends ICompteur {
   static int counter = 0;
   override increment() {counter ++}...
};
 
....
 
A a = new A
B b = new B
 
a.increment();
b.increment();

Ce n'est peut-etre pas la solution la meilleur ceci dit...

Salutations,

Greg

[PRomu@ld]

Ce que tu proposes n'es qu'une implémentation dans un langage bien particulier de ce que dahtah proposait en première solution (la surcharge en plus)

[dahtah]

Tout d'abord merci de vos réponse...
Je trouve l'utilisation d'une interface interressante, pour la réutilisation du code...
Est-il possible d'utiliser des compteurs non-statiques (apparement les méthodes static ralentissent franchement le code à l'éxecution)? Je ne vois pas trop comment faire...

[PRomu@ld]

(apparement les méthodes static ralentissent franchement le code à l'éxecution)?

Tu as un argument objectif pour étayer cette thèse ?

[pseudocode]

Tu as un argument objectif pour étayer cette thèse ?

Moi aussi je suis tres dubitatif sur cette affirmation...

[Jedai]

Est-il possible d'utiliser des compteurs non-statiques (apparement les méthodes static ralentissent franchement le code à l'éxecution)? Je ne vois pas trop comment faire...

C'est exactement le contraire dans tous les langages objets que je connais (le dispatch statique est forcément plus rapide que le dispatch dynamique au runtime...).

--
Jedaï

[dahtah]

D'accord. J'avais entendu ça au travail.
Apparement c'était faux...
Pourriez vous développer un peu?
Merci.

[alex_pi]

D'accord. J'avais entendu ça au travail.
Apparement c'était faux...
Pourriez vous développer un peu?
Merci.

Généralement, si tu fais appelle à une méthode statique, tu précises le nom de la classe. Auquel cas, le compilo sait *à la compilation* quelle classe c'est, et donc exactement qu'elle méthode c'est. Il peut faire un bête appel de fonction.

Dans le cas d'une méthode d'instance, dans un langage comme java, il y a résolution au runtime. En effet, si tu as un tableau d'objet de la classe Bestiole, et que tu appelles la méthodes manger(herbe), le comportement ne sera pas le même si en fait ton objet est de la classe Lion (héritant de la classe bestiole) ou de la classe Mouton. Il y a donc une analyse à faire au run-time. Donc c'est plus lent. Hop.

[dahtah]

Parfait, Merci.

[genteur slayer]

l'utilisation de compteur estvraiment trop vaste à mon avis pour avoir sa propre classe.... de plus comme cela peut s'applique à des objets aussi diverses que variés c'est très difficile de faire des compteurs dynamiques génériques

je suis également parfaitement d'accord sur les vitesses d'exécution Java est très pratique pour les programmeur mais très très très lent à l'exécution à cause des résolution de noms dynamique