Discussion :

[elseve31]

Bonjour,

Dans ma classe Activite, j'ai 31 getters et 31 setter correspondant au jour du mois. Ils sont déclarés de la façon suivante, de getJ01 à getJ31 pour les getter et de setJ01 à setJ31 pour les setter.

Pour l'instant mon code ressemble à ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
      //Création d'une nouvelle activité 
                int idIdc = Integer.parseInt(request.getParameter("contrat"));
                act = new Activite();
                act.setCreation(true);
                act.setIdIdc(idIdc);
                act.setJ1(0);
                act.setJ2(0);
                act.setJ3(0);
                ...
                ...
                act.setJ28(0);
                act.setJ29(0);
                act.setJ30(0);
                act.setJ31(0);

Excusez moi de ce que vous allez voir mais c'est pour bien vous montrez ce que je veux faire. Je souhaiterais faire une boucle de la sorte :

Code :

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

1
2
3
4
5
6
7
8
      //Création d'une nouvelle activité 
                int idIdc = Integer.parseInt(request.getParameter("contrat"));
                act = new Activite();
                act.setCreation(true);
                act.setIdIdc(idIdc);
                for (int i=0; i<31; i++){
                act.setJ+i+(0);
                }

Merci d'avance pour vos réponses.

[Uther]

Techniquement, pour faire ça il te faudrait recourir a l'introspection: http://ricky81.developpez.com/tutori...pi/reflection/

Ceci dit est tu sur que gérer un getter/setter par jour est vraiment ce dont tu as besoin?
Ça ne me parait pas une conception judicieuse.

[bigbear19]

Salut,

Je pense que c'est surtout ta structure de données qu'il faut revoir.
Es-tu obligé d'avoir un setter par jour ?
Sinon à quoi sert l'entier en paramètre du setter et comment est-il stocké ?

A priori il serait déjà plus pratique d'utiliser un tableau d'entiers et un setter général.

Si tu nous dis ce que tu souhaites faire, on pourra peut être t'aider davantage.

[Benouze]

Bonjour,

Ceci ne fonctionnera pas :

Code :

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

act.setJ+i+(0);

Pourquoi ne pas initialiser les attributs dans ton constructeur ?

Code :

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

1
2
3
4
5
6
7
8
9
10
public Activite() {
  super();
  j1 = 0;
  j2 = 0;
  j3 = 0;
  ...
  j29 = 0;
  j30 = 0;
  j31 = 0;
}

Edit : Ou mieux, comme l'ont indiqué les intervenants précédents, voir si un tableau ou une Collection (une map ?) ne conviennent pas mieux

[elseve31]

Tout d'abord merci pour vos réponses.

Je développe une application web en J2ee. J'ai une table en base de données qui s'appelle Activite qui a donc les 31 champs des 31 jours du mois. Dans ces champs, je saisi le nombre d'heures effectués par un employé de mon entreprise.
Le code que je vous ai montré avec act.setJ1(0),...,act.setJ31(0) me sert à initialiser une nouvelle activité. Ici je vous ai montré cette exemple parce qu'il est simple, mais j'aurai besoin de refaire des manipulations de ce genre pour d'autres fonctions de mon application. Donc pour répondre à votre question : Es-tu obligé d'avoir un setter par jour ? Je pense que oui.

[ipingu]

Avec un pojo de ce type :

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
 
public class ManyGetter {
 
	private int jour1;
	private int jour2;
 
	public int getJour1() {
		return jour1;
	}
	public void setJour1(Integer jour1) {
		this.jour1 = jour1;
	}
	public int getJour2() {
		return jour2;
	}
	public void setJour2(Integer jour2) {
		this.jour2 = jour2;
	}
}

Tu peux utiliser ce code pour appeler tes setters dynamiquement :

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
 
import static org.junit.Assert.assertEquals;
 
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
 
import org.junit.Test;
 
public class ManyGetterTest {
 
	@Test
	public void testGetters() {
		ManyGetter foo = new ManyGetter();
		Class fooClass = foo.getClass();
		String methodName = "setJour";
		Method method = null;
 
		try {
			for (int i = 1; i <= 2; i++){
				method = fooClass.getMethod(methodName + i, Integer.class);
				method.invoke(foo, 1);
			}
		} catch (SecurityException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		} catch (NoSuchMethodException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		} catch (IllegalArgumentException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		} catch (IllegalAccessException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		} catch (InvocationTargetException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
 
		assertEquals(1, foo.getJour1());
		assertEquals(1, foo.getJour1());
 
	}
 
}

Seul point, les parametres des getters sont des Integer, et non int.

[Yomhgui]

La seule bonne solution est celle évoquée par bigbear19.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public class Activite {
 
    private int[] _count = new int[31];
 
    public int getJ(int index) {
        return _count[index);
    }
 
    public void setJ(int index, int value) {
        _count[index] = value;
    }
 
}

L'introspection ne sert réellement que dans deux cas:
* Pour écrire des environnements de développement, qui par nature ont besoin de désassembler le code, des outils liés à la compilation et au déploiement... ce genre de choses.
* ... ben non en fait, il n'y a pas d'autre cas pertinent. On peut toujours (et on a tout intérêt à) se passer du RTTI et de ses dérivés (réflexion Java).

[Yomhgui]

Je n'avais pas fait attention à ton post concernant les EJB. Dans ce cas, la structure de test objets est certainement très liée au modèle de données de la base dans laquelle les données persistent. Évidemment, s'il y a une table ACTIVITE qui possède les champs J1, J2, ..., J31, ça va être délicat de faire quelque chose de vraiment clean mais du coup le problème de modélisation se trouve plus côté du data model.