Organisation des classes

Version imprimable

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:

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:

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 ?

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

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:

1 2 3 public static void main(String[] args) { new MainClass().showMainWindow(); }
Etant bien entendu que les noms des méthodes sont tous fantaisistes...

10/12/2011, 20h13
thelvin

Citation:

Envoyé par Jeannot40

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.)

Citation:

Envoyé par Jeannot40

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.
10/12/2011, 22h16
Jeannot40
Citation:

Envoyé par BenWillard

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

Ah merci ça c'est nettement plus clair.
Citation:
Envoyé par BenWillard

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

Code:

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.

Citation:

Envoyé par BenWillard

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

Nous sommes bien d'accord
10/12/2011, 23h19
thelvin
Citation:

Envoyé par Jeannot40

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

?
Code:

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

Bon voilà à quoi j'arrive:
Code:

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 ?

11/12/2011, 16h32
thelvin

Citation:

Envoyé par Jeannot40

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.

Citation:

Envoyé par Jeannot40

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.

Citation:

Envoyé par Jeannot40

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é.

Citation:

Envoyé par Jeannot40

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.)
11/12/2011, 17h36
Jeannot40
Citation:

Envoyé par thelvin

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++.

Citation:

Envoyé par thelvin

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:

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:

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

Citation:

Envoyé par Jeannot40

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.

Citation:

Envoyé par Jeannot40

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.
Citation:
Envoyé par Jeannot40
Alors j'essaye de contourner ça :
Code:

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:

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:

machin.new Truc();

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

Code:

machin.newTruc();

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

12/12/2011, 01h06
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:

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 ;)

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

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:

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 :

Citation:

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.