Discussion :

[Jeannot40]

Bonjour

Je débute en java et je me demande comment organiser au mieux mes classes pour avoir quelque chose de clair et propre.

Alors j'ai penser faire une classe principale MainClass (ou MonProgrammeDeLaMortQuiTue), qui contienne la méthode main, et qui gérerais l'ensemble des autres classes, en particulier les événement qui se passe dans l'UI. L'idée est de disjoindre la partie fonctionnelle de la partie graphique

Voilà ce que ça donne en test avec une fenêtre.

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
 
package MW;
 
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.border.EmptyBorder;
import javax.swing.JTextField;
import javax.swing.JButton;
 
public class MainWindow extends JFrame {
 
	private JPanel contentPane;
	public JTextField textField;
	public JButton btnNewButton;
 
	/**
         * Launch the application.
         */
 
 
	/**
         * Create the frame.
         */
	public MainWindow() {
		setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
		setBounds(100, 100, 450, 300);
		contentPane = new JPanel();
		contentPane.setBorder(new EmptyBorder(5, 5, 5, 5));
		setContentPane(contentPane);
		contentPane.setLayout(null);
 
		textField = new JTextField();
		textField.setBounds(10, 11, 86, 20);
		contentPane.add(textField);
		textField.setColumns(10);
 
		btnNewButton = new JButton("New button");
		btnNewButton.setBounds(137, 10, 89, 23);
		contentPane.add(btnNewButton);
	}
}

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
46
47
48
49
50
51
52
53
54
55
56
57
 
package MW;
 
import java.awt.EventQueue;
import java.awt.event.MouseAdapter;
import java.awt.event.MouseEvent;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
 
import javax.swing.JOptionPane;
 
public class MainClass {
 
	private static MainClass main = new MainClass();
	private static MainWindow frame;
 
	public static void main(String[] args) {
		EventQueue.invokeLater(new Runnable() {
			public void run() {
				try {
					frame = new MainWindow();
				} catch (Exception e) {
					e.printStackTrace();
				}
				initFrame();
			}
		});
	}
 
	private static void initFrame(){
		frame.setVisible(true);
		frame.addWindowListener(main.new WindowClose());
		frame.btnNewButton.addMouseListener(main.new NewButtonClick());
	}
 
	class NewButtonClick extends MouseAdapter {
		public void mouseClicked(MouseEvent e) {
			JOptionPane.showMessageDialog(null, "Vous avez saisie " + frame.textField.getText(), 
											"information", JOptionPane.OK_OPTION);
 
		}
	}
 
	class WindowClose extends WindowAdapter {
		public void windowClosing(WindowEvent e) {
			 //Ici on demande la confirmation de fermeture de l'application
			int reponse = JOptionPane.showConfirmDialog(null, "Voulez-vous vraiment quitter ?", "Confirmation", JOptionPane.YES_NO_OPTION);
			if (reponse == JOptionPane.YES_OPTION){
		                //Sauvegarde des préférences                
 
		                //Quit l'application
				System.exit(0);
			}	
		}
	}
 
}

J'ai bataillé pour faire fonctionner ça jusqu'à que j'ai l'idée d'instancier un objet statique MainClass à l'intérieur d'elle même. Cela m'a tout débloqué. Je trouve ça bizarre d'avoir du faire cette déclaration, car java devait le faire je pense de manière implicite pour pouvoir fonctionner. Reste que cet objet implicite est inaccessible car pas nommé. j'ai essayé avec this cela ne fonctionne pas. J’espère que du coup je me retrouve pas avec 2 objets différents MainClass, ce qui risque de me poser des problèmes.

Si j'ai bien compris, avec cette méthode, je suis condamné à programmer toutes mes instanciations d'objet à l'intérieur de la méthode run, elle même à l'intérieur de la méthode main, et qui constitue la boucle principale du programme. C'est un peu lourd je trouve. Il n'y a pas une meilleure solution ?

[JoeChip]

Dans le main (statique, donc) de ta classe, tu peux instancier une classe non statique :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
class MainClass {
    class MainThread implements Runnable {
         public void run () {
               new MonServeurDeLaMort(new LeLogTropBienFoutu()).start();
               new MaFenetreQuiDechireTout().setVisible(true);
         }
    }
    public static void main(String[] args) {
        new MainThread().start();
    }
}

Mais bon, c'est juste un exemple, sous le coup de l'inspiration... Tu peux aussi, simplement, instancier la classe en faisant :

Code :

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

1
2
3
    public static void main(String[] args) {
        new MainClass().showMainWindow();
    }

Etant bien entendu que les noms des méthodes sont tous fantaisistes...

[thelvin]

J'ai bataillé pour faire fonctionner ça jusqu'à que j'ai l'idée d'instancier un objet statique MainClass à l'intérieur d'elle même. Cela m'a tout débloqué. Je trouve ça bizarre d'avoir du faire cette déclaration, car java devait le faire je pense de manière implicite pour pouvoir fonctionner. Reste que cet objet implicite est inaccessible car pas nommé. j'ai essayé avec this cela ne fonctionne pas. J’espère que du coup je me retrouve pas avec 2 objets différents MainClass, ce qui risque de me poser des problèmes.

Il semble que tu ne comprennes pas la notion de static. main() est une méthode statique et n'a donc pas besoin d'une instance de la classe pour être appelée. Par conséquent, il n'y a pas de construction d'instance de cette classe juste parce que c'est la classe principale, puisqu'il n'y en a aucun besoin.

Tu ne nous montres rien qui explique que construire un objet statique t'ait débloqué. Je pense que c'est parce que ta classe a plusieurs choses statiques qui ont besoin d'être initialisées, et que tu as fait cette initialisation dans le constructeur. Donc elle ne se fait que quand on cosntruit un objet, et à chaque fois qu'on en construit un.
C'est mal :
- Si une classe a besoin de code d'initialisation, il doit être appelé une et une seule fois. Cela doit se faire dans les initialisations de variables statiques, ou éventuellement dans un bloc statique. Pas dans un constructeur.
- On a jamais vraiment besoin de trucs statiques, et pour ce que tu fais ce n'est certainement pas le cas. Ne fais rien de statique, apprends plutôt à faire les choses sans. Après, beaucoup plus tard, quand yu y repenseras, tu verras si ce n'est pas plus pratique en statique. (Dans ton cas, non, peu probable.)

Si j'ai bien compris, avec cette méthode, je suis condamné à programmer toutes mes instanciations d'objet à l'intérieur de la méthode run, elle même à l'intérieur de la méthode main, et qui constitue la boucle principale du programme. C'est un peu lourd je trouve. Il n'y a pas une meilleure solution ?

Toutes les instanciations qui ont lieu au démarrage du programme doivent être appelées quelque part par cette méthode, oui. Mais tout ce qui est instancié plus tard, en cours d'utilisation, ça doit être appelé par ce qui en a besoin et c'est tout.

Note au passage que cette méthode de départ, elle peut appeler autant d'autres méthodes qu'elle veut. Tu n'es pas obligé de mettre cent millions de lignes dans cette méthode. Tu peux déléguer à d'autres.

[Jeannot40]

Dans le main (statique, donc) de ta classe, tu peux instancier une classe non statique :

Ah merci ça c'est nettement plus clair.

Mais bon, c'est juste un exemple, sous le coup de l'inspiration... Tu peux aussi, simplement, instancier la classe en faisant :

Code :

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

1
2
3
    public static void main(String[] args) {
        new MainClass().showMainWindow();
    }

Oui mais si on fait comme ça les objets n'étant pas nommés on ne peut plus les manipuler après.

Etant bien entendu que les noms des méthodes sont tous fantaisistes...

Nous sommes bien d'accord

[thelvin]

Oui mais si on fait comme ça les objets n'étant pas nommés on ne peut plus les manipuler après.

?

Code :

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

1
2
3
4
5
public static void main(String[] args) {
  MainClass instance = new MainClass();
  instance.showMainWindow();
  instance.faireEncoreDAutresChoses();
}

[Jeannot40]

Bon voilà à quoi j'arrive:

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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
 
package MW;
 
import java.awt.EventQueue;
import java.awt.event.MouseAdapter;
import java.awt.event.MouseEvent;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
 
import javax.swing.JOptionPane;
 
public class MainClass {
 
	private static MainClass main = new MainClass();
	private MainWindow frame;
 
	public static void main(String[] args) {
		EventQueue.invokeLater(main.new MainThread());	
	}
 
	class MainThread implements Runnable {
		public void run() {
			try {
				frame = new MainWindow();
			} catch (Exception e) {
				e.printStackTrace();
			}
			initFrame();
			//Construction d'autre objets (non statiques) utiles  durant toute la vie du prog
 
		}
	}
 
	private void initFrame(){
		frame.setVisible(true);
		frame.addWindowListener(main.new WindowClose());
		frame.btnNewButton.addMouseListener(main.new NewButtonClick());
	}
 
	class NewButtonClick extends MouseAdapter {
		public void mouseClicked(MouseEvent e) {
			JOptionPane.showMessageDialog(null, "Vous avez saisie " + frame.textField.getText(), 
											"information", JOptionPane.OK_OPTION);
 
		}
	}
 
	class WindowClose extends WindowAdapter {
		public void windowClosing(WindowEvent e) {
			 //Ici on demande la confirmation de fermeture de l'application
			int reponse = JOptionPane.showConfirmDialog(null, "Voulez-vous vraiment quitter ?", "Confirmation", JOptionPane.YES_NO_OPTION);
			if (reponse == JOptionPane.YES_OPTION){
		                //Sauvegarde des préférences                
 
		                //Quit l'application
				System.exit(0);
			}	
		}
	}
 
}

Effectivement, je pensais que l'espace mémoire était alloué qu'à la construction d'un objet, y compris pour les membres ou méthodes static (au premier objet, après les autres s'en servent). Alors que non, pour les membres et méthodes static, il est alloué à la compilation, ce qui fait que l'on peut y accéder sans instanciation. Logique, il faut bien pouvoir attaquer la méthode Main.

Mais je suis quand même obligé de garder un objet static main du type MainClass, dont j'ai besoin au moindre new de classes secondaires déclarées dans MainClass. L'alternative étant de déclarer ces classes hors de MainClass, mais alors il faudrait que je leur passe les objets ou que je les déclare public.

Mais effectivement j'arrive à créer des objets non statique dans le run.

EventQueue.invokeLater peut-il servir a quelque chose? Et ne faut-il pas garder un handler (qui sera forcément statique) sur l'objet de type MainThread ?

[thelvin]

Effectivement, je pensais que l'espace mémoire était alloué qu'à la construction d'un objet, y compris pour les membres ou méthodes static (au premier objet, après les autres s'en servent). Alors que non, pour les membres et méthodes static, il est alloué à la compilation, [...]

Non, au chargement de la classe. En Java les classes sont chargées avant leur première utilisation.

Mais je suis quand même obligé de garder un objet static main du type MainClass, dont j'ai besoin au moindre new de classes secondaires déclarées dans MainClass.

Pas besoin de conserver cet objet dans une variable statique, tu n'as qu'à le passer dans le constructeur de tous les objets qui ont besoin de passer par lui.
J'ai dit : on a jamais besoin de static. Quand on s'en sert ce n'est que par commodité. Donc, tu n'en as pas besoin. Chaque fois que tu le crois, repenses-y. Et viens poser la question si besoin.

EventQueue.invokeLater peut-il servir a quelque chose?

Cela sert à exécuter du code sur le thread de gestion des évènements de UI. En anglais, le Event Dispatch Thread, abrégé EDT. En principe on est censé passer par là pour démarrer la construction de la UI, et ne pas le faire peut poser des problèmes dans certaines circonstances rares.

Note qu'en général on utilise plutôt SwingUtilities.invokeLater() qui fait la même chose en un petit peu moins spécialisé.

Et ne faut-il pas garder un handler (qui sera forcément statique) sur l'objet de type MainThread ?

Pas si tu n'as pas de raison de le faire (et tu n'en auras pas.)

[Jeannot40]

Non, au chargement de la classe. En Java les classes sont chargées avant leur première utilisation.

Merci de cette précision. Moi et mes raisonnement de C++.

Pas besoin de conserver cet objet dans une variable statique, tu n'as qu'à le passer dans le constructeur de tous les objets qui ont besoin de passer par lui.
J'ai dit : on a jamais besoin de static. Quand on s'en sert ce n'est que par commodité. Donc, tu n'en as pas besoin. Chaque fois que tu le crois, repenses-y. Et viens poser la question si besoin.

Ce n'est pas par commodité mais par obligation. La méthode main étant static (ce qui est normal il faut bien un point d'entrée fixe au programme), tous les objets instanciés dedans doivent l'être.
Alors j'essaye de contourner ça :

Code :

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

1
2
3
4
5
6
 
private void initFrame(){
		frame.setVisible(true);
		frame.addWindowListener(new MainClass.WindowClose());
		frame.btnNewButton.addMouseListener(new MainClass.NewButtonClick());
	}

Là ça va.

Code :

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

1
2
3
4
 
public static void main(String[] args) {
		EventQueue.invokeLater(new MainClass.MainThread());	
	}

Là ça va plus Eclipse me dit que MainThread est inaccessible et qu'il lui faut un objet, alors qu'il est dans le même scope que WindowClose ou que NewButtonClick

[thelvin]

Ce n'est pas par commodité mais par obligation.

Non. Je t'ai dit qu'à chaque fois que tu pensais cela, tu devais y repenser (sous-entendu jusqu'à ce que tu ne le penses plus.)

Je t'accorde que la méthode main(), elle, doit être static. C'est une convention de départ. Il n'y a pas d'autre cas.

La méthode main étant static (ce qui est normal il faut bien un point d'entrée fixe au programme), tous les objets instanciés dedans doivent l'être.

Je ne vois pas ce rapport de cause à effet.
Les objets peuvent être instanciés sans être gardés dans une variable. Ils peuvent aussi l'être dans une variable locale, dont la portée est limitée à la méthode. Il n'est pas nécessaire de les garder dans une variable statique.

Alors j'essaye de contourner ça :

Code :

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

1
2
3
4
5
6
 
private void initFrame(){
		frame.setVisible(true);
		frame.addWindowListener(new MainClass.WindowClose());
		frame.btnNewButton.addMouseListener(new MainClass.NewButtonClick());
	}

Là ça va.

En principe cela ne marche pas, non. Sauf si les classes WindowClose et NewButtonClick sont déclarées static.

Inutile. main.new WindowClose() marchait très bien, mais main n'a aucun besoin d'être static.

Il suffit de construire une instance de MainClass dans le constructeur de MainThread, et de la garder dans une variable de MainThread.

Possible aussi, quelque chose de ce genre :

Code :

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

1
2
3
4
5
6
7
8
9
public static void main(String[] args) {
  MainClass main = new MainClass();
  main.faireToutLeResteDuDémarrage();
}
 
private void faireToutLeResteDuDémarrage() {
  // faire éventuellement des trucs
  SwingUtilities.invokeLater(new MainThread());
}

À noter :

- d'habitude on aime pas la notation

Code :

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

machin.new Truc();

On préfère définir une méthode newTruc() dans la classe de machin, et faire :

Code :

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

machin.newTruc();

Bon, dans le cas présent c'est limite une question de goûts.

[tchize_]

Bon bon bon, alors dans l'ordre.

Pourquoi t'as besoin de faire main.new SousClasse()? Tout simplement parce que SousClasse, comme tu l'a défini, est une inner classe liée à une instance d'une classe englobante. Pour résoudre ce problème, il suffit d'utiliser un mot magique: static

Code :

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

1
2
3
4
5
6
7
8
public class Main {
   public static void main(String[] args){
      new MaClasse(); //yippie ça marche
   }
   public static class MaClasse { 
//.....
   }
}

Ensuite, pour revenir à la question de départ, organisation. Désolé, ce n'est pas dans les bonne pratique. Je note que tu fais bien l'instanciation dans le thread EDT (bien vu), mais je ne mettrais pas dans Main la logique.
Si tu veux séparer ton interface de ta logique buisness, il y a une interface toute faite pour toi: Action, et son implémentation AbstractAction. Tu peux alors découper ton code comme-cui:

Plusieurs classes Action qui font le travail logique (NewClientAction, DeleteClientAction, etc)
Une classe "fenetre" qui instancie les différentes actions (ou demande une classe Controlleur de lui filer les Action)
Un main qui instancie la fenetre (et éventuellement le controlleur)

Bref, ta classe Main devrait se restreindre à parser la ligne de commande et lancer la fenetre

[Jeannot40]

Bon je pense avoir tenu compte de vos remarques à tout deux et voilà à quoi j'arrive :

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
 
import java.awt.EventQueue;
 
public class MainClass {
 
	public static void main(String[] args) {
		MainClass main = new MainClass();
		main.startAppli();
	}
 
	private void startAppli(){
		EventQueue.invokeLater( new MainThread());	
	}
 
}

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
46
47
48
49
50
51
 
import java.awt.event.MouseAdapter;
import java.awt.event.MouseEvent;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;
 
import javax.swing.JOptionPane;
 
class MainThread implements Runnable {
 
	private MainWindow frame;
 
	public void run() {
		try {
			 frame = new MainWindow();
		} catch (Exception e) {
			e.printStackTrace();
		}
		initFrame();
		//Construction d'autre objets utiles durant toute la vie du prog
 
	}
 
 
	private void initFrame(){
		frame.setVisible(true);
		frame.addWindowListener(new WindowClose());
		frame.btnNewButton.addMouseListener(new NewButtonClick());
	}
 
	class NewButtonClick extends MouseAdapter {
		public void mouseClicked(MouseEvent e) {
			JOptionPane.showMessageDialog(null, "Vous avez saisie " + frame.textField.getText(), 
											"information", JOptionPane.OK_OPTION);
 
		}
	}
 
	class WindowClose extends WindowAdapter {
		public void windowClosing(WindowEvent e) {
			 //Ici on demande la confirmation de fermeture de l'application
			int reponse = JOptionPane.showConfirmDialog(null, "Voulez-vous vraiment quitter ?", "Confirmation", JOptionPane.YES_NO_OPTION);
			if (reponse == JOptionPane.YES_OPTION){
		                //Sauvegarde des préférences                
 
		                //Quit l'application
				System.exit(0);
			}	
		}
	}
}

Effectivement, plus de membre ou de méthode static, et c'est beaucoup plus propre.

Bon je trouve quand même que la MainClass est très maigre, et si mon souci est de bien organiser mon code avec des classes ayant des missions précises j'aimerais aussi éviter de me retrouver avec une flopée de classes/fichiers de 10 lignes qui ne feront chacune pas grand chose et dans laquelle on a du mal à naviguer et à s'y retrouver. Je pense qu'il y a là un équilibre à trouver, qui ne peut venir qu'avec l'expérience, mais vous m'aidez bien en me donnant des pistes.


@tchize : j'ai regardé l'interface Action, et comme ils disent :

Note that Action implementations tend to be more expensive in terms of storage than a typical ActionListener, which does not offer the benefits of centralized control of functionality and broadcast of property changes. For this reason, you should take care to only use Actions where their benefits are desired, and use simple ActionListeners elsewhere.

Je crois que pour mes besoins pour l'instant simples, il vaut mieux que je reste avec les ActionListeners. Mais je retiens si j'ai des besoins plus complexes (éléments de menu avec icone, info_bulle et tout le tralala). Et là, si ça devient complexe, hop classe séparée bien rangée dans son fichier.