Discussion :

[Teovald]

Bonjour,

Je code depuis quelques années, et en java depuis un an. Je suis actuellement dans un stage où j'utilise ce langage tous les jours ou presque (lui et le c# principalement pour être exact); je commence donc à être très à l'aise avec et à bien connaître java et swing.
Mais j'ai quelques interrogations par rapport aux bonnes pratiques de ce langage (ou de tout langage de POO en fait) : je suis par exemple en train de créer une application fouillant le code source d'un très gros programme pour y effectuer quelques opérations, les opérations en elle mêmes ne me posent pas de problème, mais c'est sur la structure du programme lui même que je me pose des questions.
Par exemple, si j'ai une application simple qui utilise une seule classe (et éventuellement 2 ou 3 inner classes); est-ce une mauvaise pratique d'avoir un main qui me sert uniquement à créer une instance de cette classe, le constructeur se chargeant alors d'initialiser tous les champs(normal) et de lancer mon algorithme?
Ou est-ce que je devrais me servir de mon constructeur uniquement pour initialiser les valeurs de mes variables, et ensuite appeler dans mon main des fonctions de cette classe? (ou même avoir 2 classes, une contenant seulement le main et l'autre la classe qui contient toutes les variables & fonctions)

Je sais bien que dans tous les cas mon application fonctionnera à priori aussi bien; mais je me demande juste s'il y a certaines pratiques à éviter, et quelles lignes de conduite suivre.
Et j'ai également la même question pour une application java-swing.

Merci d'avance pour vos réponses, c'est une questions tellement générale que je ne l'ai vue traitée nulle part.

[merill]

Il vaut mieux ne pas lancer de long traitements dans un constructeur.
Tu construit ton objet, puis tu lui fait subir des traitements, ou alors tu utilise une fabrique.
Sinon, cela bloque le thread courant à l'initialisation, c'est pas très lisible.

[Népomucène]

Si l'application ne comporte qu'une seule classe, il est exact que l'on peut placer le code aussi bien dans le main que dans le constructeur.
On peut même se passer de constructeur si le programme ne doit pas instancier plusieurs fois la classe
et ne fait appel qu'à des méthodes statiques (alors autant programmer en vba, cela ira encore plus vite )

Sans parler d'héritage, interface, et autre ; il faut se demander si la classe va être utilisée par d'autres classes.
Si c'est le cas alors il faut bien sûr placer l'initialisation des variables dans le constructeur.

[Teovald]

merci, c'est le genre de considérations que je voulais connaître.
Donc quelque chose comme:

main(..) {
Objet item = new Objet()
item.operation1();
item.operation2();
item.operation3();
}

Objet() {
lecture du fichier de config, initialisation des File, remplissage des ArrayList,...
}


serait meilleur que:

main(..) {
Objet item = new Objet()
}

Objet() {
lecture du fichier de config, initialisation des File, remplissage des ArrayList,...
operation1();
operation2();
operation3();
}

?

[Teovald]

Si l'application ne comporte qu'une seule classe, il est exact que l'on peut placer le code aussi bien dans le main que dans le constructeur.
On peut même se passer de constructeur si le programme ne doit pas instancier plusieurs fois la classe
et ne fait appel qu'à des méthodes statiques (alors autant programmer en vba, cela ira encore plus vite )

Sans parler d'héritage, interface, et autre ; il faut se demander si la classe va être utilisée par d'autres classes.
Si c'est le cas alors il faut bien sûr placer l'initialisation des variables dans le constructeur.

je fais ce programme en java car il reprend de manière automatisée ce que j'avais déjà rendu possible au sein d'une interface graphique; ça me permet donc de gagner un peu de temps en reprennant une partie de mon code.
Oui; dans l'absolu je devrais pouvoir rendre mes variables et methodes statiques et me passer de constructeur, j'en utilise un par habitude et pour rendre mon code plus lisible (comme je l'ai dit je ne suis dans cette boite que le temps d'un stage et ce programme devra être réutilisé par d'autres).

[Népomucène]

Franchement, dans ce cas particulier, je ne crois pas que cela fasse une grosse différence dans les performances.
Mais, d'accord avec merill, il vaut mieux avoir un petit constructeur et appeler les méthodes après (dans le main).
C'est en effet plus lisible et plus facile à maintenir.

[Teovald]

Je me doute bien que niveau performances ça ne changera pas grand chose; je veux juste prendre de bonnes habitudes et avoir un code facile à lire/maintenir.

Surtout que les performances ne sont à priori pas un problème pour l'appli, je fais quelques traitements assez lourd que je cherche à optimiser un minimum, mais vu que c'est pour un outil qui sera seulement utilisé de temps en temps et uniquement par les devs et pas les clients finaux, ce n'est pas bien grave s'il lui faut tourner pendant 1 minute avant de fournir le résultat.

Merci de vos réponses en tout cas.

[karimDevelopper]

Bonjour,
j'essaie de créer une file jms toute simple, mais pour la lancer....
je suis sous workshop, qd je lance l'appli, j'ai une erreur main class not found, car j'ai enlevé " weblogic system library" et ajouter "wlclient.jar"
Merci

[Rei Ichido]

merci, c'est le genre de considérations que je voulais connaître.
Donc quelque chose comme:

main(..) {
Objet item = new Objet()
item.operation1();
item.operation2();
item.operation3();
}

Objet() {
lecture du fichier de config, initialisation des File, remplissage des ArrayList,...
}


serait meilleur que:

main(..) {
Objet item = new Objet()
}

Objet() {
lecture du fichier de config, initialisation des File, remplissage des ArrayList,...
operation1();
operation2();
operation3();
}

?

La question, c'est que font tes opérations ?
Même si actuellement ton projet est simple, il peut se complexifier ; le principe des bonnes pratiques c'est aussi de faciliter les évolutions.

Un constructeur est censé initialiser un objet. On peut alléger l'initialisation, en particulier quand il y a des valeurs qui peuvent être null, et se contenter ensuite de getter/setter. Mais par contre, faire plus que de l'initialisation, ça semblerait difficilement compréhensible par les autres développeurs ; ils seraient certainement surpris en faisant appel au constructeur de lancer des opérations ... à moins que ces dernières ne soient faites dans le cadre de l'initialisation