Discussion :

[Micke7]

Bonjour,

Afin d'éviter de créer plusieurs instances d'objets ne le nécessitant pas (par exemple des communes) (Singleton?), je souhaiterais les charger au lancement de mon application.
J'ai codé quelque chose qui fonctionne mais je ne suis pas sûr que c'est la meilleure des solutions. Je vous demande donc votre avis
Le but ici est de charger des objets de type Commune.

Pour cela j'ai créé:
.une classe Commune (possédant id,libelle etc etc)
.une interface SingletonCtrl contenant la définition d'une méthode nommée LoadData().
.une interface CommuneCtrl héritant de l'interface SingletonCtrl et contenant les définitions de méthodes propres aux objets Commune.
.une classe CommuneCtrlImpl implémentant donc l'interface CommuneCtrl et surchargeant donc les méthodes de CommuneCtrl et de SingletonCtrl.
.et enfin une classe Singleton possédant une méthode statiques loadSingletons() dans laquelle je renseigne les classes héritant de SingletonCtrl (à voir si cela peut être fait automatiquement) et j'appelle les méthodes loadData() de ces différentes classes.

La méthode en question

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
 
 public static void loadSingletons() throws ControleurException{
	Class classeEnCours = null;
 
	listeClassCtrlSingleton = new ArrayList<Class>();
	listeClassCtrlSingleton.add(CommuneCtrlImpl.class);
	listeClassCtrlSingleton.add(VarieteCtrlImpl.class);
 
	try {
	    for (Class classe:listeClassCtrlSingleton){
		classeEnCours = classe;
		Method[] tablMethode = classe.getMethods();
		for (int i=0;i<tablMethode.length;i++){	
		    if (tablMethode[i].getName().contains("loadData")){
			tablMethode[i].invoke(classe.newInstance());
		    }
		}
	    }
	} catch (IllegalArgumentException e) {
	    gestionErreur(e,classeEnCours);
	} catch (IllegalAccessException e) {
	    gestionErreur(e,classeEnCours);
	} catch (InvocationTargetException e) {
	    gestionErreur(e,classeEnCours); 
	} catch (InstantiationException e) {
	    gestionErreur(e,classeEnCours);
	}
    }

Ainsi, pour charger toutes mes données, je fais un Singleton.loadSingletons(); dans ma classe Main.

Comme expliqué précédemment, le code fonctionne mais j'ai un gros doute concernant sa simplicité, son respect des normes etc etc.

Merci d'avance à ceux qui s'attarderont sur mon problème

[professeur shadoko]

Uuuergh ... compliqué.
est-ce que tu sais utiliser des blocs static dans des classes?
chaque classe aurait son bloc static qui sera executé au chargement.
serait-ce pas plus simple?

[Micke7]

Salut professeur shadoko,

Je souhaiterais faire en sorte d'obliger la déclaration d'une méthode de chargement de données pour les classes concernées donc, sauf erreur de ma part, je suis obligé de passer par une interface commune, et il n'est pas possible de déclarer des classes statiques dans les interfaces.

Ou alors n'ai-je pas bien compris ton idée?

[LittleBean]

et il n'est pas possible de déclarer des classes statiques dans les interface

Effectivement

Je souhaiterais faire en sorte d'obliger la déclaration d'une méthode de chargement de données pour les classes concernées donc, sauf erreur de ma part, je suis obligé de passer par une interface commune,

Pourquoi passer par une méthode ? Quelle en est l'utilité ?
Je pense qu'un bout de code présentant l'appel de ces données, pourrait éclairer ta demande.

La solution "bloc static" est des plus élégantes pour ton besoin, la jvm se charge d’exécuter le code lors de la première utilisation de la classe, tu es ainsi assuré :
- unicité de l’exécution du code
- le code aura toujours été joué avant que tu en ais besoin

[Mako 5013]

La solution "bloc static" est des plus élégantes pour ton besoin, la jvm se charge d’exécuter le code lors de la première utilisation de la classe, tu es ainsi assuré :
- unicité de l’exécution du code
- le code aura toujours été joué avant que tu en ais besoin

Arrêtez-moi si je me trompe, mais cela n'est pas vrai tout le temps, non ?

Par exemple, si la classe possède des méthodes statiques et que l'on commence par appeler une de celles-ci, l'appel à la méthode se fera avant l'appel au bloc static (qui ne se fera pas du tout en fait). C'est particulièrement gênant dans le cas de classes utilitaires ne comprenant que des méthodes statiques.

Mako.

[wax78]

Tu te trompes, avec ce petit exemple, quoiqu'il arrive, tu va voir "block static", puis "turlututu" apparaitre si tu utilises quoi que ce soit de la classe eee;

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 eee
{
	static double V = 0;
	static
	{
		System.err.println("block static");
		V = 3;
	}
	public static void main(String[] args)
	{
                      // eee.V = 15; marche aussi
		eee.test();
	}
 
	public static void test()
	{
		System.err.println("Turlututu");
	}
}

[LittleBean]

Arrêtez-moi si je me trompe, mais cela n'est pas vrai tout le temps, non ?

Tu te trompes

http://docs.oracle.com/javase/tutori...O/initial.html

To provide the same capability for class variables, the Java programming language includes static initialization blocks

En gros les blocs statics sont définis (fonctionnellement) comme des constructeurs pour les variables de classe.

[professeur shadoko]

Effectivement

Si: il est possible de déclarer une classe statique dans une interface.

[LittleBean]

Si: il est possible de déclarer une classe statique dans une interface.

Hum il y quelque chose qui m’échappe... c'est quoi : "une classe statique dans une interface"

Pour moi dans une interface :
- champs static ok
- bloc static ko
- méthodes static ko

[Mako 5013]

Tu te trompes

Tiens, j'aurais au moins appris quelque chose aujourd'hui...

Je me souviens pourtant d'un cas (tordu) où je ne passais pas dans le bloc static. Il s'agissait peut-être d'une classe abstraite avec uniquement des méthodes statiques (il faudrait que je recherche).

En tout cas, merci pour l'info.

Mako.

[tchize_]

Le plus simple, ce serait pas simplement de faire ce code, éventuellement?

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 static class SingletonControlleur{
   private static SingletonControlleur instance = new SingletonControlleur();
 
   public SingletonControlleur getInstance(){return instance;}
 
 
   private List<Commune> communes = initCommunes();
   private List<Varietes> varietes = initVarietes();
 
   // getters sur les listes
 
   // initXxxx()
 
}

exemple d'appel

Code :

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

SingletonControlleur.getInstance().getCommunes();

[tchize_]

Maintenant, si tu veux vraiment jouer avec tes controlleur:

Code :

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

1
2
3
public interface Controlleur{
   public void loadDatas() throws ControleurException;
}

singleton:

Code :

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

1
2
3
4
5
6
7
8
9
public static void loadSingletons() throws ControleurException{
 
	listeCtrlSingleton = new ArrayList<Controlleur>();
	listeCtrlSingleton.add(new CommuneCtrlImpl());
	listeCtrlSingleton.add(new VarieteCtrlImpl());
 
	for (Controlleur controlleur:listeCtrlSingleton)
               controlleur.loadDatas();           
    }

pas besoin de reflection pour ça

[tchize_]

Je me souviens pourtant d'un cas (tordu) où je ne passais pas dans le bloc static.

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 Test {
    static {
       system.out.println("static 1");
    }
    private static Test test = new Test();
 
    static {
       system.out.println("static 2");
    }
 
    public Test(){
        System.out.println("constructor");
    }
}

peut-être? (Ici le deuxième bloc statique est appelé après le constructeur)

[Mako 5013]

C'est bon, j'ai réussi à refaire mon cas.

J'ai deux classes abstraites ClasseMere.java et ClasseFille.java (la seconde héritant de la première).

Elles sont comme ceci :

Code ClasseMere.java :

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

1
2
3
4
5
6
7
8
9
10
11
 
public abstract class ClasseMere {
 
     /** Logger */
     protected static Log logger;
 
     public static void maMethode() {
          // on fait ce que l'on a à faire
          logger.debug("coucou");
     }
}

Code ClasseFille.java :

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

1
2
3
4
5
6
7
 
public class ClasseFille extends ClasseMere {
 
     static {
          logger = Log.getInstance();
     }
}

Dans ce cas, si dans mon code je fais ceci : ClasseFille.maMethode(), j'aurais une erreur me disant que le logger est null (et effectivement, je ne passe pas dans le bloc static de la classe fille).

Mako.

[LittleBean]

Ton cas est cohérent avec la doc :

The runtime system guarantees that static initialization blocks are called in the order that they appear in the source code

Les statics sont exécutés dans l'ordre dans lequel ils se trouvent dans le code source.

J'étais jamais tombé sur ton cas, c'est vrai que ça peut paraître curieux au premier abord .

[tchize_]

Dans ce cas, si dans mon code je fais ceci : ClasseFille.maMethode()

Dans ce cas ton IDE devrais t'avoir mis un warning, car ce n'est pas ClasseFille que tu utilise, mais ClasseMere, il n'y a pas héritage des données et méthodes statiques en java, autrement dit, ClassFille n'a aucune méthode maMethode et n'est pas impliquée, et le compilateur stockera

Code :

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

 invokestatic ClasseMere.maMethode()V

dans le bytecode. A aucun moment cela n'impliquera le chargement de la classe ClasseFille.


Bref, c'est pas un problème d ebloc statique, c'est un problème de compréhension du language java et de la manière dont sont résolu les appels aux méthodes statiques.


De la même manière, si je fait

Code :

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

1
2
ClassFille uneFille = getFille() ; // retourne null
uneFille.maMethode();

même si uneFille est null, ca ne déclenchera pas d'exception, et aucun passage par uneFille !

[Mako 5013]

Dans ce cas ton IDE devrais t'avoir mis un warning

Non.

il n'y a pas héritage des données et méthodes statiques en java, autrement dit, ClassFille n'a aucune méthode maMethode et n'est pas impliquée, et le compilateur stockera

Code :

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

 invokestatic ClasseMere.maMethode()V

dans le bytecode

Bon à savoir.

Merci pour toutes ces précisions.

Mako.

[tchize_]

Non.

Ha ben oui, j'aurais du vérifier. C'est pas un warning, car ça peux être voulu si tu prévois de pouvoir cacher la méthode du parent

Code :

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

1
2
3
4
5
6
	public class Test1 {
	   public static void maMethode(){}
	}
	public class Test2 extends Test1 {
		   public static void maMethode(){}
	}

[professeur shadoko]

Hum il y quelque chose qui m’échappe... c'est quoi : "une classe statique dans une interface"

Pour moi dans une interface :
- champs static ok
- bloc static ko
- méthodes static ko

champs static ok si final

Code :

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

1
2
3
4
5
6
7
8
9
10
 
public interface MonInterface {
    static class MaClasse {
       // y compris des blocs static
        public MaClasse(){
 
        }
    }
    public MaClasse faisLe() ;
}